Two quotes, same features, $40,000 apart
A founder shows us two proposals for the same MVP. One is $22,000 and eight weeks. One is $62,000 and fourteen weeks. The feature lists are close to identical — same screens, same core workflow, same integrations named. The founder's question is reasonable: is the expensive one padding, or is the cheap one lying?
Usually neither. The expensive quote has priced the work that does not demo. The cheap quote has priced the demo. Both are internally honest; only one of them describes a system you can put real users on.
The eight line items that separate them
Across the builds we have taken over from another vendor, the same eight items are missing from the low quote. They are not exotic. They are simply invisible in a walkthrough:
- Authentication and session management. Not a login form — password reset, session expiry, brute-force protection, and a decision about SSO before your first enterprise prospect asks for it.
- A permissions model. Who can see which record. Retrofitting this is the single most expensive omission on the list, because it touches every query in the system rather than sitting in one module.
- Three environments. Local, staging, production. Teams testing in production do not discover this is a problem until the first customer sees a half-finished feature.
- Automated deployment. If shipping requires someone to remember a sequence of steps, that person becomes a single point of failure and deploys become rare, which makes each one riskier.
- Error monitoring. Without it you learn about failures from customers. With it you learn from a dashboard, usually before they notice.
- Database migrations. A repeatable, versioned way to change the schema. Absent this, every structural change is a manual operation someone performs nervously against live data.
- Automated backups, with a tested restore. An untested backup is a belief, not a backup.
- Tests around the highest-churn code. Not full coverage — coverage where you actually change things, so that changing them stops being frightening.
None of these are features. All of them are prerequisites. A quote that omits them is not cheaper; it is smaller.
Why the omission compounds
Retrofitting is more expensive than building, and the multiplier is not uniform. Adding error monitoring later is close to free — it is largely configuration. Adding a permissions model later means revisiting every data access path in the codebase, which is why it is the item most likely to trigger a rebuild conversation eighteen months in.
The pattern generalises: the later a cross-cutting concern arrives, the more code it has to cut across. Authentication, permissions and the data model are all cross-cutting. Monitoring, backups and CI are not. Sequence accordingly — if the budget forces a choice, take the cross-cutting items first and defer the ones that bolt on cleanly.
| Cross-cutting | Auth, permissions, data model — retrofit cost scales with codebase size |
|---|---|
| Bolt-on | Monitoring, backups, CI — retrofit cost is roughly flat whenever you do it |
| The rule | Buy cross-cutting early; defer bolt-on without guilt |
What the research says about why this happens
The Standish Group's CHAOS research has tracked software project outcomes for three decades across tens of thousands of projects. Its consistent finding is that small projects succeed dramatically more often than large ones, and that the dominant failure factors are not technical — they are unclear objectives, changing requirements and weak executive sponsorship.
That maps onto MVP economics precisely. The cheap quote is not failing because the developers are worse. It is failing because 'MVP' was never defined, so scope moved, and the non-functional work was the first thing sacrificed to protect the visible feature list. The build then ships, works in a demo, and cannot take load, users, or a second customer's edge cases.
The scope conversation that actually protects a budget
Before a line of code, get written answers to five questions. Ambiguity in any one of them is where the money goes:
- What is the smallest thing a real user would pay for? Not the vision. The first transaction.
- Which external systems must it talk to on day one? Each integration carries its own auth, error handling, rate limits and failure modes. Deferring one removes real cost, not theoretical cost.
- Is this codebase disposable or foundational? Both are legitimate. Pretending a prototype is a foundation is not.
- Who can say no? One named person. Committees do not protect scope; they enlarge it.
- What is the definition of done? Written before the build, not negotiated at the end of it.
How to read a quote once you know this
Ask any vendor to price authentication, permissions, environments, deployment, monitoring, migrations, backups and tests as separate line items. Three things happen. A vendor who has already included them shows you where. A vendor who has not will tell you they are 'not needed for an MVP', which is now a claim you can evaluate. And a vendor who becomes uncomfortable has told you something useful for free.
This is also why our Build engagements are milestone-gated rather than time-and-materials. A milestone gate forces both sides to define done before work starts, which is exactly the discipline the CHAOS data says separates the projects that land from the ones that drift.
Where we would tell you not to hire us
If your build is genuinely a single-purpose internal tool with no external integrations, no compliance surface and fewer than a dozen users, most of this article does not apply to you. Buy the cheap quote, or build it on a no-code platform, and spend the difference on distribution.
The eight line items earn their cost when the software has to survive real users, a second customer, an auditor, or a diligence process. If none of those are on your horizon in the next two years, the production-grade version is over-engineering and we will say so on the call.