The wrong fear: "software projects always spiral out of control"
Few numbers get quoted in software-budget conversations as often as "most IT projects fail or blow their budget". What almost never comes with it: where that number comes from, and which kind of project it actually describes. The Standish Group has published its CHAOS Report regularly since the 1990s, sorting software projects into "successful", "challenged" and "failed" – averaged across all project sizes, the success rate has sat around a third for years. That's exactly the blended figure that circulates as the scare statistic in advisory conversations.
The crucial part of the CHAOS data almost always gets left out: broken down by project size, the success rate splits dramatically – small, tightly scoped projects reach success rates around 90%, large projects under 10%. That's not a gradual slope, it's a break. Applying the blended horror number to the decision to build a first prototype means applying a statistic to a situation it was never measured for.
What actually goes wrong on large IT projects – and why that's a different case
The second frequently cited cost-explosion study comes from McKinsey and the University of Oxford (2012, over 5,400 IT projects examined): large-scale projects starting at $15 million ran 45% over budget on average, 7% over time, and delivered 56% less value than planned. One rarely-cited detail is particularly telling: every additional year of project duration increased the cost overrun by another 15 percentage points. 17% of the projects studied went so far out of control (200 to 400% budget overrun) that, per the study, they threatened the continued existence of the company involved.
These numbers describe a structurally different mechanism than an MVP: on multi-year large-scale projects, complexity compounds over time – new stakeholders, changing requirements, technical debt reinforcing each other. An MVP sprint, by contrast, typically runs a few weeks. The takeaway isn't "MVPs are automatically safe" – it's that anyone afraid of MVP costs shouldn't orient themselves by numbers drawn from a completely different risk category.
The real driver for MVPs: not technology, scope
If technical complexity isn't what blows the budget, what is? Industry data on MVP and startup development shows a consistent pattern: feature creep – requirements added during implementation – is consistently cited as by far the most common reason for budget overruns, averaging roughly 27% additional cost over the original quote. Conversely, teams that formally prioritise core functionality before kickoff report 20 to 40% lower total costs on average, for comparable outcomes.
The mechanism behind this is unglamorous but important to understand: every later "can we just quickly add..." request doesn't just cost the time for the new feature itself – it creates new dependencies and new test cases that overlap with parts already built. That's the real reason small change requests feel like "just a detail" but hit the invoice disproportionately hard.
What a fixed-price quote actually prices in
This is exactly where a mechanism kicks in that rarely gets named openly in quote conversations. Several independent analyses of software development contract models converge on the same pattern: vendors build a risk premium of often 15 to 50% on top of the pure implementation estimate into a fixed-price quote – a buffer against exactly the scope ambiguity that still exists at contract signing. For clearly defined, tightly scoped projects, the same analyses suggest fixed price tends to run roughly 10 to 15% cheaper than time-and-materials billing; for projects with scope that's still unclear or still evolving, that flips – there, time-and-materials is often 20 to 40% cheaper, because no uncertainty premium is being paid "just in case".
The consequence is easy to state but rarely put this plainly: economically, a fixed price is insurance. As with any insurance, the assessed level of risk sets the premium – and the risk level on an MVP quote is determined almost entirely by how clearly the vendor can assess the actual scope at the moment they calculate it.
The flaw in the thinking that follows from this
That produces an inversion missing from most price comparisons: a noticeably high or "padded"-looking fixed price isn't primarily a sign of a greedy or inexperienced vendor. More often, it's a measurement of how much ambiguity about your own scope is still on the table at the moment the quote gets written. A vendor pricing honestly has to account for that ambiguity – anything else would be economically risky for them. The flaw in the thinking is reacting to a high quote by first looking for a cheaper vendor, instead of first sharpening the requirement that caused that price in the first place.
Conversely: whoever does a hard prioritisation before the first quote – what's core, what's "later" – directly changes the vendor's risk calculation, and with it the price. That's not a negotiating trick; it's a direct consequence of how risk premiums get calculated in the first place.
Does AI solve this? The data says: not the part that matters
The obvious expectation is: if AI coding tools speed up development, MVP costs should have dropped noticeably in recent years. A recent, methodologically solid study contradicts that intuition clearly. METR, a research organisation specialising in AI evaluation, ran a randomised controlled trial with experienced open-source developers in early 2025: with AI assistance, they took 19% longer on their tasks on average than without it – despite feeling roughly 20% faster subjectively. That gap between felt and actually measured productivity is itself the subject of ongoing research.
Other recent analyses of AI coding assistants paint a more nuanced but similar picture: productivity gains of 20 to 30% are demonstrable, but concentrate heavily on specific, well-scoped work steps – not spread evenly across a project. (We covered this pattern of a "jagged frontier" between tasks AI solves well and near-identical-looking tasks it reliably doesn't in an earlier article.) Particularly telling for the MVP question: AI agents reliably stall or flag the spot as needing clarification when they hit ambiguity requiring business context, architectural decisions, or knowledge outside the code itself – they don't resolve the ambiguity, they just surface it.
That lets us answer the headline question precisely: AI tools tend to lower the cost of execution – writing code for already clearly defined, recurring tasks. They don't lower the cost of clarification – understanding exactly what should be built. Per the data from the earlier sections, though, clarification, not execution, is the actual cost driver for MVPs. For most MVP budgets, AI tools are optimising the wrong bottleneck.
What this means for your MVP budgeting
The four preceding sections add up to a framework that differs from the usual cost discussion – not "how do I find the cheapest vendor", but "how do I lower the risk premium every honest vendor has to price in":
- Forget the large-project horror numbers for your MVP decision: they come from a different risk category with a different failure mechanism (complexity compounding over years) than a week-scale sprint (scope clarity at the start).
- Prioritise hard before requesting a quote: what's the one core thing the first prototype has to prove? Everything else is "later" – that's the most effective lever, not vendor choice.
- Read a high fixed price as a signal, not just a number: a noticeably high price often shows where the vendor still sees ambiguity – exactly where a second clarifying round pays off before negotiating.
- Don't expect AI tools to halve your cost: they help where scope is already clear – not with making it clear. That remains work that has to happen before the actual building starts.
None of these points replaces a concrete estimate for a specific idea – that needs the actual facts of the idea itself. But this much can be said clearly: a structured clarification step before pricing isn't extra effort on top of the budget – it's the reason the budget is trustworthy afterwards at all.