You've seen the chart in a testing deck: a bug costs a dollar to fix in design, ten in development, a hundred in QA, and a thousand in production. It's used to justify enormous investments in up-front process. The underlying research is real, from Barry Boehm in the 1970s. The famous multiplier, though, is considerably shakier than the confident chart suggests, and knowing which part holds up changes what you should actually do.
Key Takeaways
- Boehm's curve (1976) found defects cost dramatically more to fix the later they're caught, with post-release running roughly 100x the early cost (Boehm's curve).
- The 100x figure is contested: critics argue the underlying evidence is weak (what it really costs).
- Boehm himself later indicated the ratio is closer to 5:1 for small, non-critical systems (the debate).
- The direction holds up even where the multiplier doesn't: earlier is cheaper, and fast feedback is the real lesson.
What Boehm Found
In 1976, Barry Boehm published analysis showing that defects become more expensive to fix the later in the lifecycle they're discovered (Boehm's curve). The canonical illustration: a defect that costs a small amount to fix at the requirements or design stage costs roughly ten times that during coding, a hundred times during testing, and up to a hundred or more times in production and maintenance. The mechanism is intuitive. A requirements mistake caught on a whiteboard is an eraser; the same mistake caught after release means rework across design, code, tests, docs, plus deployment, customer impact, and possibly data cleanup.
Why the 100x Number Is Contested
This is where the confident chart gets less confident. Laurent Bossavit, in The Leprechauns of Software Engineering, traced the citation chain behind these numbers and concluded the underlying evidence doesn't meet a reasonable standard, with figures repeated for decades while the original data supporting them stayed thin (what it really costs to fix a defect).
Boehm himself moderated the claim. By around 2001 he indicated that for small, non-critical systems the ratio looks more like 5:1 than 100:1. Other analyses find the cost curve is flatter on small projects than large ones, and that for certain non-critical classes of defect the cost to fix stays fairly constant across phases (the debate).
So the honest position: the direction is well supported and matches everyone's experience, while the precise exponential multiplier is folklore dressed as data, especially for small modern projects with fast deploys.
| Claim | Status |
|---|---|
| Later fixes cost more | Well supported |
| Roughly 100x by production | Contested, weak evidence |
| ~5:1 on small non-critical systems | Boehm's own later estimate |
| Flatter curve on small projects | Supported by later analyses |
What Actually Follows
If you take the 100x number literally, you conclude you should invest enormously in up-front requirements and design to catch everything early, which is the argument waterfall was built on. If you take the honest version, you reach a different and better conclusion: what matters is feedback speed rather than up-front exhaustiveness.
The reason a production bug is expensive is mostly the distance between making the mistake and learning about it. Shorten that distance and the cost collapses, which is exactly what modern practice does: fast CI, small code reviews, trunk-based development with small batches, feature flags, and observability so problems surface in minutes. Those beat trying to think of everything in advance, which the cone of uncertainty says you can't do anyway.
A Concrete Version
A team quotes the 100x chart to justify a six-week requirements phase for a new feature, on the theory that catching problems on paper is a hundred times cheaper. They write exhaustive specs. Then the feature ships and users immediately do three things nobody anticipated, because the unknowns were never the kind you can spec your way out of. A second team spends four days on a rough design, ships behind a flag to 5% of users in week two, and finds those same three problems in production, cheaply, because the blast radius was tiny and the fix was a flag flip. The second team caught bugs "late" and paid far less.
The Honest Counterpoint
Fast feedback is not a licence to skip design thinking, and there's a real category of decision where up-front care genuinely does pay Boehm-like dividends. Data models, security architecture, and API contracts that external parties depend on are all expensive to change later, exactly the irreversible decisions where thinking ahead beats iterating. Some domains, medical devices, aviation, payments, also carry consequences where "ship and learn" is unacceptable. The nuance: shorten feedback loops for the reversible majority, and invest real design effort in the small set of decisions you genuinely cannot undo cheaply.
What This Means for Teams
The practical lesson is to stop arguing about the multiplier and start shortening the loop. Every hour you cut between writing a mistake and discovering it makes the whole question less important. That's what the modern delivery stack is for, and building it well is exactly the foundational work experienced engineers set up early. It also means treating the 100x chart as a motivation rather than a measurement, and being appropriately skeptical when any strikingly clean number gets repeated without a source, a habit that would have caught more than one widely-cited software statistic. See available engineers.
Frequently Asked Questions
Does it really cost 100x more to fix a bug in production?
The direction is well supported, later is more expensive, but the specific 100x multiplier is contested. Critics found the underlying evidence weak, and Boehm himself later suggested closer to 5:1 for small, non-critical systems.
Where did the 100x figure come from?
Barry Boehm's 1976 analysis of defect costs across lifecycle phases. The figure has been repeated for decades, though later scrutiny found the original supporting data thinner than the confident charts imply.
So should we invest heavily in up-front requirements?
Usually not. The real driver is feedback speed rather than up-front exhaustiveness. Fast CI, small reviews, small batches, feature flags, and observability shrink the gap between mistake and discovery, which is where the cost lives.
When does up-front design genuinely pay off?
For decisions that are expensive or impossible to reverse: data models, security architecture, and public API contracts, plus safety-critical domains where shipping to learn is unacceptable.
The Bottom Line
Later bugs do cost more, but the famous 100x chart is folklore wearing a lab coat, and Boehm himself walked it back for smaller systems. The durable insight is about distance: cost tracks how long a mistake goes undiscovered. Shorten that gap with fast pipelines, small batches, flags, and observability, save deep up-front design for the decisions you can't undo, and the multiplier stops mattering.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
