Every buyer wants the same thing at the start of a software project: a number. Every honest supplier knows that the number they can give on day one is the least reliable number they will ever produce. That tension is not a sales problem. It is a description of the work.
Here is what actually drives cost, why the early estimate misses, and how to budget sensibly anyway.
The build is rarely the expensive part
When people picture a software budget, they picture engineers writing the features on the list. That work is real, and it is usually the most predictable part of the project. The cost overruns live elsewhere.
- Integrations with systems you do not control. An API you have never used is an unknown until someone has used it. Documentation is optimistic; behaviour is not.
- Data migration. Moving ten years of operational data out of a spreadsheet and into a system with rules means discovering that the data never obeyed those rules.
- Permissions and edge cases. 'Managers approve leave' becomes eleven rules once you ask what happens when the manager is the one on leave.
- Getting it into production. Environments, deployment, monitoring, backups and the first two weeks of real usage.
- Adoption. Training, parallel running and the changes people ask for once they use it for real.
A quote built purely from a feature list prices the first item and quietly assumes the rest away.
Why fixed quotes on vague scope fail both sides
A supplier asked to fix a price against an underspecified brief has exactly two options. Pad the number heavily to cover what they cannot see, or quote tight and recover the difference through change requests. The first loses them the work. The second wins it and poisons the relationship by month three.
A fixed price is only meaningful against a fixed scope. If the scope is still a conversation, the price is still a guess wearing a suit.
This is not an argument for open-ended time and materials. It is an argument for doing the scoping as a deliberate, paid, time-boxed piece of work — and fixing the price once there is something real to fix it against.
What a realistic budget looks like
Rather than one number, ask for three things.
- 01A cost for finding out. Two to three weeks of scoping and technical design, at a fixed fee, producing requirements, an architecture and a delivery plan you own regardless of who builds it.
- 02A range for the first release, with the assumptions written down. Ranges are honest. A single figure to the nearest thousand on day one is not.
- 03An annual running cost. Hosting, third-party services, monitoring, support and the continued development that every live system needs. Software that is maintained costs money every year. Software that is not maintained costs more, later, all at once.
Questions that separate a real estimate from a hopeful one
- What have you assumed about the systems we need to integrate with, and what happens to the estimate if those assumptions are wrong?
- What is explicitly out of scope?
- Who does the data migration, and has anyone looked at our actual data?
- What does the first release deliberately leave out, and why that split?
- What will this cost us to run for a year after launch?
A supplier who answers these easily has built this kind of system before. A supplier who treats them as obstacles is pricing a project they have not yet understood.
The cheapest way to spend less
It is not a lower day rate. It is a smaller first release. Almost every expensive software project we have seen got expensive because version one tried to be complete instead of useful. Ship the part that changes how the business works, learn from it in production, and let what you learn decide what gets built next. That sequencing saves more money than any negotiation on rates.