What custom software really costs, and the five things that move the price

The short answer, and why it cannot be a single number

Custom software is priced by scope, not by the item, so any firm that quotes you a number before understanding your process is guessing. What moves the price is predictable: how many workflows the system handles, how many other systems it must connect to, how much legacy data has to move, how many types of users and permissions it needs, and how much of it can be assembled from standard components. As one public reference point, Aezion's Clutch profile lists a minimum project size of $25,000 and hourly rates of $50 to $99; where a given project lands above that minimum depends on those five factors.

I get the price question on almost every first call, and I understand why. A CFO or owner needs a number to plan around, and a board wants to know the size of the commitment before it approves a single meeting. The trouble is that two companies describing the same idea in one sentence can need very different systems once you look at how their work actually flows. The goal of this guide is to show you how that number gets built, so you can read any proposal, including ours, with a sharper eye.

Where the hours on a software project actually go

Most people picture a software budget as programmers typing. Writing code is the largest single piece, but it is far from the only one. When we at Aezion estimate a project, the hours fall into a handful of buckets, and a proposal that leaves any of them out is not cheaper, it is incomplete.

The buckets below are the ones to look for in every quote you receive. If a line is missing, ask whether it is excluded, included somewhere else, or simply forgotten.

• Discovery and requirements: sitting with the people who do the work and documenting what the system must do.
• Design: the data model, the screens and how users move through them, reviewed with your team before build.
• Development: the application itself, delivered in increments.
• Integration: connections to accounting, ERP, payment, e-commerce or equipment systems.
• Data migration: cleaning and moving records out of spreadsheets, documents and old databases.
• Quality engineering: functional, API, mobile and load testing, plus a security review.
• Launch, training and the first stretch of support.

Five drivers that move a quote up or down

Of everything that affects price, these five account for most of the difference between a modest project and a large one. You can influence all of them, which is the good news.

Notice that the industry you are in is not on the list. A construction company and a clinic can have projects of very similar size. What matters is the complexity of the process and the systems around it, not the label on the door.

Integrations deserve a special warning because they are the driver people underestimate most. A modern accounting or payment platform with a documented interface is usually straightforward. An older ERP with no interface, a vendor who charges for access, or a piece of shop-floor equipment that only exports a file once a night can each turn a simple connection into its own small project. When you list the systems the new software must talk to, note which ones are old, which are hosted by a vendor and who at your company owns the relationship with each.

• Number of distinct workflows. Replacing one scheduling spreadsheet is a different project from replacing scheduling, inventory, invoicing and customer history at once.
• Integrations. Every outside system the software must talk to adds design, build and testing time, and some vendors make it easier than others.
• Legacy data. How much there is, how clean it is and how many years of history you need to keep all affect migration effort.
• Users, roles and rules. A tool used by a handful of people with the same access is simpler than one used by staff, managers, customers and auditors who each see different things.
• Compliance and security requirements. Health, financial and personal data bring extra design, logging and testing work.

Why two proposals for the same idea can be far apart

It is common to get proposals that differ by a wide margin for what looks like the same project. Usually the firms are not pricing the same thing. One assumed you would clean your own data; another included it. One priced a fixed scope with a large risk buffer; another priced time and materials and expects the scope to evolve. One left out testing and post-launch support entirely.

Team structure also matters. A firm that builds entirely with senior staff in one high-cost city will price differently from one that combines a local team with development centers elsewhere. We are open about our model: a Frisco headquarters with development centers in the US and India, which is how we keep total cost of ownership down. Ask every firm to explain its model plainly. My list of questions to ask a software firm before you sign covers the rest of what to compare.

Getting to a number you can take to your board

The way to turn a vague range into a reliable number is a short, paid discovery phase before the build estimate. In our Design stage we interview the people who do the work, map the real process, inventory the data and systems involved, and agree on what the first release must and must not include. The output is a documented scope and an estimate tied to it, not a guess from a one-hour call.

Discovery also protects you. If it shows that the problem can be solved by configuring a tool you already own, or that the project is not worth doing yet, you have spent a small amount to avoid a large mistake. We would rather tell you that early than build something you do not need.

A good discovery document is also portable. It describes your process, your data and the system you need in enough detail that another firm could price it. That is deliberate. You should never feel locked into a vendor because they are the only ones who understand what you asked for.

Ways to spend less without getting less

The cheapest line of code is the one nobody writes. Most of the savings on a software project come from decisions made in design, long before development starts. Here is where I see companies keep cost under control without cutting the value they need.

If you already have an old system that mostly works, it is worth asking whether to modernize the legacy application rather than rebuild it. Re-platforming what works and rebuilding only what does not is often the lower-cost path.

• Phase it. Build the workflow that hurts most, launch it, learn, then add the next.
• Use standard components where they fit, and customize only where your process is genuinely different.
• Clean your data before migration day, not during it.
• Put a decision-maker from the business in every review so questions do not sit for days.
• Write down what is out of scope for the first release, and hold the line.

The costs that begin after launch

The build is not the whole bill. Once a system is live it needs hosting, security patching, monitoring, user support and periodic updates as browsers, operating systems and connected services change. Cloud hosting and licensing for any third-party components add a recurring line as well.

Ask every firm to separate one-time build costs from recurring costs in its proposal, and to name any third-party products that carry their own license fees. A low build price paired with expensive hosting or per-user licensing can cost more over five years than a higher build price on a leaner platform. The comparison only works when both columns are visible.

None of this is a reason to avoid custom software, but it belongs in the budget from day one. I wrote a separate guide on what maintenance after launch involves, including what to put in a support agreement.

Treat it as an investment, and measure what you are replacing

A software budget only makes sense next to the cost of the current way of working. Before you compare proposals, estimate what the existing process costs you each year: hours spent re-entering data, time to produce key reports, errors that reached customers, work you turned down because the tools could not handle it. The self-assessment in my guide on replacing the spreadsheet that runs your company is a good place to start.

Then look at how the project will be paid for and when the benefit arrives. Phasing helps here, because each release starts returning value before the next one is funded. If cash timing is the real constraint, a conversation with a fractional CFO about cash flow before you commit can be time well spent.

What to bring to a first pricing conversation

You will get a far more useful conversation, from us or anyone else, if you come with a few things written down. You do not need a specification; a page of plain notes is enough.

With that in hand, a first call with us covers what you are trying to fix, whether custom software is the right answer at all, and what a discovery phase would look like for your situation. Dallas-area companies can meet us in Frisco; many clients work with us remotely from the start.

• The process that hurts most, in your words, and who does it today.
• Every tool, spreadsheet and system that touches that process.
• The systems the new software must connect to.
• Any compliance requirements, such as health or financial data rules.
• Your timing and the budget range you are considering, even if it is rough.

Questions people ask me