Describe the same software idea to three development companies and you will often receive three wildly different numbers. It is not unusual to see a 10x spread — $10,000 from one vendor, $40,000 from another, $120,000 from a third. To a buyer, this is bewildering. Someone must be wrong. But the more useful conclusion is that the question itself was under-specified, and each vendor answered a different question.
A quote is a mirror of an assumption
When a requirement is vague, a vendor has no choice but to fill the gaps with assumptions — and those assumptions drive the price. The $10,000 quote may assume a thin prototype with no real security, no scale, and no edge cases. The $120,000 quote may assume production-grade architecture, integrations, testing, and a team that will still be there in a year. Both may be quoting honestly. They are simply quoting different products.
This is why price comparison, done naively, is close to meaningless. You are not comparing the cost of the same thing; you are comparing the cost of three different imagined things.
What actually drives the number
- Scope — how much is genuinely being built, and how much is quietly deferred or excluded.
- Non-functional requirements — performance, security, availability and scale are invisible on a screen but enormous in effort.
- Architecture — a throwaway build and a system designed to last cost very different amounts.
- Team seniority and location — the day rate and the mix of people assigned.
- Risk appetite — a low quote often prices out the risk that later returns as a change request.
How to read the spread
The spread is information. A very low quote is rarely a bargain; it is usually a signal that scope has been minimised, risk has been deferred, or the vendor intends to make its margin on change requests once you are committed. A very high quote may reflect genuine rigour — or simply a vendor with expensive overheads and little incentive to be lean. Neither number can be judged until the requirement, architecture, performance expectations, security standards, scalability and acceptance criteria are properly defined.
The answer cannot be determined until the requirement is properly defined. Establish the benchmark before you commit, not after.
This is precisely the work of independent specification and estimation. Define what is being built with enough precision that every vendor quotes the same thing — then benchmark those quotes against an independent estimate of the effort. Once you do, the 10x spread usually collapses, and the outliers explain themselves.