The 10x–100x Rule: What a Late Fix Actually Costs
Everyone "knows" it is cheaper to fix a problem early. Almost nobody knows how much cheaper, which is why teams keep making the expensive choice. Here is the number, where it comes from, and what to do about it.
The cost-to-fix curve
Barry Boehm’s work on software engineering economics produced the classic figures for the relative cost of fixing a defect at each stage of the lifecycle. A requirement error caught while writing the requirements costs 1x. The same error caught later costs:
- Requirements phase — 1x (the baseline: a conversation and a sentence).
- Design — 3–6x.
- Code — 10x.
- Test — 15–40x.
- After delivery — 100x or more.
Why the multiplier compounds
The exact multipliers vary by study, but the shape is consistent and the order of magnitude is not in dispute: the later a defect is found, the exponentially more it costs to fix.
A requirement error is not an isolated typo. It spawns work in every phase that follows. The wrong requirement becomes the wrong design, which becomes wrong code, wrong tests, wrong documentation, and a wrong expectation living in the support queue.
When you finally catch it, you are not fixing one line — you are undoing a tree of decisions that all grew from the same mistaken seed. That is why the multiplier compounds instead of adding.
What 100x looks like in practice
At the requirements stage, a wrong requirement is fixed with a sentence and an hour. The same requirement, discovered after delivery, becomes: a release stopped, a patch planned, a rollback executed, documentation corrected, a support team briefed, and a customer reassured — weeks of work across multiple teams, plus the cost of whatever the bug did in the wild.
The money is only half of it. The other half is opportunity: while the team is undoing the mistake, it is not building anything new.
The lever: move discovery left
You cannot prevent every wrong requirement. You can move the moment of discovery to where it is cheapest — a discipline with a name: shift left. It means reviewing requirements before design, prototyping the risky ones before committing, and asking the hard questions while they still cost a conversation instead of a quarter.
The arithmetic is simple. An hour spent questioning a requirement early buys back the hundred hours it would cost to fix late. That is the entire business case for requirements engineering, stated as a number.