Two proposals arrive for what reads like the same brief. One is three times the other. Neither team is lying.
This happens constantly, and founders usually resolve it by assuming the expensive one is padded or the cheap one is inexperienced. Sometimes that is true. More often the two teams are pricing different amounts of work, because they made different assumptions about what they will find when they open your system, and neither wrote those assumptions down.
Here is what actually moves the number.
1. The architectural starting condition
This is the single largest variable and it is invisible in a brief.
Two products can both work, both serve real customers, and both look identical from the outside, while one is three times more expensive to extend. The difference is whether the original architecture anticipated the direction you are now going.
A system built with a single enforcement point for tenant isolation can change its isolation model as a project. A system where isolation depends on every query including the right filter has to be audited line by line first, and the audit is the expensive part, not the change.
Any team quoting without inspecting this is quoting a guess. Any team that inspects it and then explains what they found is telling you something worth more than the quote.
2. How much of your data model is load-bearing debt
Not all technical debt costs the same. Debt in a feature nobody uses is free. Debt in your data model is the most expensive kind of debt there is, because everything sits on top of it and changing it means migrating live customer data without losing any of it.
The specific things that drive cost here: identifiers that were never designed to be stable, denormalised data that has drifted out of agreement with its source, columns holding several different meanings depending on a status field, and the absence of any historical record so you cannot reconstruct what a value used to be.
A team that opens your schema and goes quiet is not being difficult. They have just found where the budget is going.
3. The integration surface
Every external system your product touches is a source of cost that scales non-linearly. Not because integrations are hard to write, but because each one is a dependency you do not control, with its own rate limits, its own failure behaviour, its own versioning schedule, and its own support responsiveness when something breaks at your busiest hour.
Five integrations is not five times the cost of one. It is five times the surface area plus the coordination cost of failures that involve more than one of them at once.
When you compare two proposals, check whether both teams counted the same integrations, and whether either of them asked what happens when each one is unavailable.
4. Compliance, and when it arrives
Compliance requirements are cheap when designed in and very expensive when retrofitted. This is the most predictable cost surprise in the entire category.
Audit logging is the clearest example. Threading an audit trail through a write path that was not built for one means touching every operation that changes state. If you have a hundred such operations, that is a hundred changes, each needing review and testing, before you have a single new feature to show a customer.
Data residency has the same shape. So does the right to delete, if nobody designed for it and personal data has propagated into caches, logs, backups and analytics.
If you know an enterprise customer is coming, the compliance work is cheaper now than it will ever be again.
5. Decision latency on your side
The cost driver nobody puts in a proposal, and one of the largest in practice.
Engineering work stalls waiting for decisions. Which of these two behaviours is correct. Do we support the legacy import format. Who signs off on the new permissions model. Every day a decision sits unresolved is a day of paid capacity producing less than it could.
Teams that have done this before build decision points into the plan and name who owns each one. If a proposal in front of you does not identify who on your side decides what, that is a risk you are carrying without pricing it.
Why the hourly rate tells you almost nothing
An hourly rate is a measure of what an hour costs, not of how many hours the work takes. Two teams at very different rates routinely arrive at similar totals, because the more experienced team has seen the problem before and does not spend a fortnight discovering it.
Worse, hourly billing puts you and your supplier on opposite sides of the same question. Every hour saved is revenue lost for them. Nobody in that arrangement is deliberately dishonest, but the incentive is pointed the wrong way, and incentives win over intentions on a long engagement.
What to ask instead of the rate: what is the outcome, how is done defined, what happens if it takes longer than estimated, and who carries that. Those four answers tell you more about a supplier than any number on the first page.
How to compare two proposals honestly
Check whether both teams inspected the system or only read the brief. Only one of those is a quote.
Check whether the scopes actually match. Line them up item by item. They usually do not, and the difference is often the entire price gap.
Check what each proposal assumes it will find. If neither states its assumptions, ask. The answer is revealing.
Check who owns architectural decisions, and whether decisions get documented as they are made or explained at the end.
Check what is excluded. The exclusions list is more informative than the inclusions list.
The question worth asking before the budget question
Before you ask what it costs, get a defensible answer to what condition the system is actually in. Without that, every number you receive is a guess wearing a spreadsheet, and you have no basis for choosing between them.
A rough way to start is to put a number on your current debt position yourself. It will not be precise. It will be considerably more useful than a feeling, and it will change the quality of the conversation you have with any supplier afterwards.
Top comments (0)