Two shops quote the same project. One says four thousand, one says twenty six. Both are describing the same outcome and neither is lying. Here is what actually sits underneath those numbers, so you can read a proposal properly.
The quote is the smallest part
Software has four costs. Proposals cover the first one.
- Building it. The number you are quoted.
- Getting it into use. Migration, training, running both ways for a while, the month where everything is slower.
- Keeping it alive. Hosting, dependency updates, security patches, the things that rot whether or not you touch them.
- Changing it. Because your business will not be the same in two years.
A cheap build with no plan for the other three is not cheap. It is a deferred invoice with interest, and the interest is usually paid at the worst moment.
Where the hours actually go
People assume the feature list is the work. On most projects we have run, the split looks roughly like this:
- The happy path: about a quarter. The demo version. Everything works, data is clean, the user does the expected thing. This is the fast part and it is why demos are misleading.
- Exceptions: about half. Duplicate submissions, the customer who changes their mind mid job, someone closing the tab at step three, a required field that turns out to be optional in real life. This is the bulk of the cost and none of it is visible in a screenshot.
- Getting data in and out: the rest. Migrating what you have, connecting what it has to talk to, and the discovery that the old export has three formats in one file.
When a quote is dramatically lower than another, it is usually because the second half is not in it. Not dishonestly. It is genuinely hard to price exceptions before you have seen the data, which is why a fixed scope with a defined exclusion list beats a low number with an open ended change process.
Cost drivers you control
Scope you actually need
The single biggest lever. Half the features in most first specifications are there because someone imagined a future user. Ship the part that runs your business next month, then decide what is real.
How clean your data is
Directly proportional. Migration into a well kept system is straightforward. Migration out of nine years of spreadsheets with inconsistent naming is a project of its own, and it is cheaper for you to do the deduplication than to pay us to.
How fast you answer questions
Underrated. A build waiting three days for a decision on what a status means is a build that costs more. The clients who get the best outcomes are the ones who named an owner and gave them authority.
How much you change your mind mid build
Some of this is healthy and any decent process expects it. But a change at design costs almost nothing, the same change after it is built costs real money, and the same change after data has been migrated costs considerably more.
The number to ask for
Not the quote. Ask for the cost of the first three years: build, plus what it costs to run each year, plus a realistic allowance for changes.
A shop that cannot give you that has not thought past the invoice. A shop whose answer includes a genuinely small ongoing number is telling you something real about the way they build, because low maintenance is a property of the code, not a pricing decision.
The expensive projects are rarely the ones that cost a lot to build. They are the ones that cost a lot to keep.
When custom is the wrong answer
If an off the shelf product does eighty percent of it and the missing twenty is not where you compete, buy the product. We have said this to people holding a budget and a signed intent to spend it.
Custom earns its cost when the process is the thing that makes you different, when you have outgrown what the tools will bend to, or when the licence cost of putting every seat on a platform has quietly passed the cost of owning something.
That last one arrives sooner than people expect. It is worth checking your per seat spend against a build once a year.
