How much does custom software actually cost?
Nobody in this industry wants to answer this question in public. Here is why the numbers vary so much, what actually drives them, and how to tell a real estimate from a hopeful one.
Ask five development companies what a piece of custom software costs and you'll get five answers spanning an order of magnitude. That is not because four of them are lying. It is because the question, as asked, has no answer - and the ones who give you a confident number immediately are usually the ones you should worry about most.
This is an attempt to answer it honestly: what actually drives cost, why estimates differ so wildly, and the specific questions that tell you whether a quote is grounded in anything.
Why nobody will give you a straight number
Software cost is dominated by one variable that cannot be assessed from a brief: how much of the problem is still undiscovered. Two projects described in the same sentence - "a booking system for our customers" - can differ by a factor of twenty depending on what happens when a booking clashes, whether it needs to know about capacity, whether capacity depends on the type of job, whether the job type changes the duration, and whether any of that has ever been written down.
That is not evasion. It is the actual situation. The useful response is not to demand a number anyway, but to ask how a supplier intends to reduce that uncertainty before you commit serious money to it.
The five things that actually drive the cost
1. How well you understand your own process
This is the biggest factor and the one clients consistently underestimate. If your process is documented, agreed and stable, a developer can build it. If it lives in three people's heads and they disagree about the details - which is normal, not a failure - then the first phase of the project is discovering the process, and that discovery has to happen whether or not anyone budgeted for it.
The expensive version is when this discovery happens during the build, one contradiction at a time, each triggering rework. The cheap version is when it happens deliberately, up front, in a phase designed for it.
2. Integrations with systems you don't control
Every connection to an external system is a dependency on someone else's decisions, documentation and reliability. A well-documented modern API is straightforward. An older system with no API, poor documentation or an undocumented rate limit can consume more time than the rest of the project combined.
The honest way to handle this is to investigate the integrations before quoting the project, not after. A supplier who hasn't asked what you need to connect to hasn't thought about your project.
3. Who uses it, and how much that costs when it goes wrong
An internal tool for five colleagues who can be told how it works is a different product from a customer-facing system where confusion costs you a sale. The functionality might be identical; the design, testing, error handling and polish are not.
Similarly, a tool where a mistake means re-typing something is cheaper than one where a mistake means an incorrect invoice, a missed compliance obligation or a damaged piece of equipment. The stakes drive how much verification the system needs, and verification is real work.
4. Data - and specifically, your existing data
Migration is the phase that gets cut from estimates and then eats the schedule. Real business data is messy: duplicates, inconsistent formats, records that violate rules everyone assumed were enforced, and fields used for something other than their name suggests.
Cleaning and migrating it properly is a project in itself. Doing it badly is how new systems lose their users in the first fortnight, because someone looks for a record they need and it is not there.
5. What happens after launch
Software is not a capital purchase that then sits there. Dependencies need updating, browsers change, providers deprecate things, and your business changes. A build quote that doesn't mention what happens in year two is describing half the cost.
Where the money actually goes
For a typical project, the split looks roughly like this - and the surprise for most people is how little of it is writing code.
| Phase | What happens | Rough share |
|---|---|---|
| Discovery | Mapping the real process, deciding what is in and out | 10-15% |
| Design | How it works and how it looks, before anything is built | 10-15% |
| Build | Writing the software | 40-50% |
| Testing and fixing | Making it actually work, including the awkward cases | 15-20% |
| Data migration | Getting your existing information in, correctly | 5-15% |
| Launch and training | Getting people using it without losing trust | 5-10% |
If a quote is almost entirely "build", it is either missing phases or assuming they will be absorbed. Both end the same way: a conversation about extra cost, halfway through.
Fixed price, time and materials, or staged?
Fixed price sounds safest and usually is not. To quote a fixed price responsibly, a supplier has to add contingency for everything they cannot yet see - so you pay for the risk whether or not it happens. And because any change threatens the margin, a fixed price creates an incentive to resist changes even when they are obviously right. You end up with exactly what you specified before you understood the problem.
Pure time and materials has the opposite problem: no ceiling and no pressure to be efficient.
The arrangement that works best in our experience is staged. Discovery is a small fixed price and produces something valuable in itself. Each build stage is quoted separately once the previous one has taught everyone something real. You can stop, change direction or change supplier at any boundary, and nobody is trapped in a plan drawn up before anyone understood the problem.
Six questions that expose a weak estimate
- "What could make this cost significantly more than you've quoted?" - a real estimate has known risks attached to it. "Nothing" is not an answer, it is a warning.
- "Which parts are you least certain about?" - anyone who has thought seriously about the project can name them immediately.
- "What is explicitly not included?" - the exclusions tell you more about a quote than the inclusions.
- "How does migrating our existing data get handled?" - if this hasn't come up before you raised it, the estimate is incomplete.
- "What does year two cost?" - hosting, maintenance, updates, support. A build price with no running cost attached is half a picture.
- "Who owns the code and where does it live?" - the answer should be: you, in your account, from the first commit.
The cheapest software is the software you don't build
Worth saying plainly, from a company that gets paid to build things: if an off-the-shelf product does 90% of what you need, use it. The remaining 10% is almost never worth the cost and ongoing responsibility of owning a custom system.
Custom earns its cost in a narrower set of circumstances than most people building it realise: when the process the software handles is part of why customers choose you, when you're paying for several tools and still doing manual work to join them up, or when per-seat pricing has stopped making sense at your size.
Scoping it down to the piece that pays for itself is usually the better move. A smaller build that earns its keep beats a bigger one abandoned in year two.