A bug found after a product ships to customers costs, on average, 100 times more to fix than the same bug caught during the design phase. That figure comes from research conducted by Barry Boehm at TRW in the 1970s and has been replicated repeatedly since. The number is so well-established, and so widely cited in engineering circles, that it borders on cliche. And yet, across the software industry, companies continue to underfund testing, rush releases, and pay the premium on the back end. The question worth asking is not whether the math is right. It is why rational, data-driven organizations keep making the same expensive mistake.

The answer involves incentives, organizational structure, and a fundamental problem with how software quality is measured and sold. As we’ve explored before, software engineers often struggle to explain what they actually build, and that opacity extends to the cost of quality itself. Prevention is invisible. Fixing things after they break is very, very visible.

The Compounding Cost Nobody Sees Coming

Boehm’s research established a cost curve that engineers call the “exponential cost of change.” A requirements error caught before any code is written might take an hour to correct. The same error caught during testing might take a week. Found in production, that same error can take months, involve legal exposure, damage customer relationships, and require coordinated work across multiple teams.

The numbers from later research are even more striking. The Systems Sciences Institute at IBM found that bugs found during implementation cost six times more to fix than those caught during design. Bugs found during testing cost fifteen times more. After release, the cost jumps to between 40 and 1,000 times the original, depending on the system’s complexity and reach.

The compounding happens because software is deeply interconnected. A bug is rarely a single error sitting alone. It is an assumption baked into one layer of a system that other layers depend on. When it surfaces late, fixing it means unwinding those dependencies, retesting adjacent features, and in many cases rewriting documentation, updating APIs, and notifying customers. The original flaw might take four hours to correct. The surrounding cleanup takes four weeks.

Why Teams Ship Bugs They Know Exist

This is where the analysis gets more uncomfortable. Many bugs that reach production are not surprises. They are known issues that were classified as low-priority, logged in a backlog, and quietly carried through to release.

The reason is structural. Engineering teams measure their output in features shipped, not defects prevented. Product roadmaps reward adding new capabilities, not hardening existing ones. When a team is choosing between building a feature that will appear on a press release and fixing a bug that will never appear anywhere, the incentive structure makes that choice almost automatic.

Software bugs also multiply as teams grow, and not because larger teams write worse code. They multiply because communication overhead increases and assumptions stop being shared. One team builds a component assuming certain inputs will always be validated. Another team integrates it assuming that validation happens elsewhere. Nobody is wrong. The bug lives in the gap between two correct assumptions.

This is compounded by the way software organizations are structured. The people who write the code are rarely the people who bear the cost when it breaks. Customer support teams absorb the complaints. Operations teams manage the outages. Engineering teams are already three features ahead. The feedback loop is broken by design.

The Prevention Tools That Exist and Go Unused

The engineering community has developed a substantial toolkit for catching bugs early. Static analysis tools scan code for common error patterns before it runs. Formal code reviews catch logical flaws that automated tools miss. Test-driven development requires engineers to write tests before they write features, which forces them to think through edge cases in advance.

These tools are not obscure. They are widely known, freely available in many cases, and actively advocated by senior engineers at every major technology company. They also require upfront time investment, which is exactly what schedule-driven development environments are unwilling to provide.

There is a well-known trick in professional engineering called “shifting left,” which means moving quality checks earlier in the development process. The phrase has become popular enough to appear on conference slides and executive presentations. Implementing it meaningfully, which requires slowing down feature development to invest in testing infrastructure, is another matter.

Some companies have found a different approach. Tech companies hire hackers to break their own products as a way of finding expensive problems before customers do. The logic is the same as Boehm’s cost curve, applied to security specifically. A vulnerability found by an internal red team costs far less than one exploited in the wild. The practice works, but it requires organizational commitment to treating prevention as a budget line, not an afterthought.

The Measurement Problem at the Root of Everything

Perhaps the deepest reason the prevention gap persists is that quality is genuinely hard to measure. A company can count the number of features shipped in a quarter. It cannot easily count the number of bugs that were never written because an engineer paused to think through an edge case, or because a code reviewer asked the right question.

This measurement gap creates a reporting problem that flows upward. Executives see velocity metrics, release cadence, and customer acquisition numbers. They rarely see prevention metrics, because those metrics are difficult to construct and almost impossible to present compellingly. Prevented bugs do not show up in dashboards. Fixed bugs do, which creates a perverse incentive to celebrate the firefighting and overlook the fire prevention.

There is also a cognitive dimension to this. Tech workers, like most knowledge workers, are prone to screen-based blind spots that make it easy to miss what is not immediately visible. A bug in a backlog feels abstract. A customer complaint feels urgent. Organizations respond to urgency, not abstraction, even when the math clearly favors the opposite.

What Rational Prevention Actually Looks Like

Companies that consistently manage bug costs tend to share a few structural characteristics. They treat testing infrastructure as a product in itself, with dedicated engineers, budgets, and roadmaps. They run retrospectives that explicitly assign cost estimates to bugs that reached production, making the price of late detection concrete and visible to leadership. And they create feedback loops that connect the engineers who write code to the teams who absorb the cost when it breaks.

None of this is complicated in theory. It requires organizational will to prioritize something whose value is measured in things that do not happen, and that is a harder sell than almost any feature on a product roadmap. The 100x cost multiplier has been known for half a century. The industry’s relationship with it says more about how organizations make decisions than it does about engineering.

The bugs were never really the problem. The incentives were.