The True Cost of Technical Debt

Part 3 ended the foundational arc: we know what debt is, where it lives, and where it comes from. Now the question that actually moves budgets — what does it cost? This is the pivot from understanding the problem to acting on it, and it is where most technical-debt arguments fail, because they reach for outrage instead of arithmetic. The case for paying down debt is not made by adjectives. It is made by naming the interest rate and showing where the money goes.

A note on the numbers in this article. Every figure is reproduced exactly as its source stated it, attributed and dated. We do not quote a cost for your system — that requires measuring it, which is Part 5. What this part does is establish the scale of the problem with credible, citable data, and name the cost categories the budget line never shows.

The cost is an interest rate, not a balance

The instinct is to ask “how big is our technical debt?” as if it were a balance on a statement. That framing misleads, because the principal — the one-time cost of doing it right — is rarely the issue. The cost that matters is the interest: the recurring tax the debt levies on every change that touches it, paid every sprint, forever, until the debt is cleared.

This reframes the whole economics. A debt with high principal but low interest — ugly code in a module nobody touches — costs you almost nothing and can be safely ignored. A debt with modest principal but high interest — a bad boundary on your most-changed path — bleeds you continuously. The cost of technical debt is a rate, and the rate is highest exactly where you are most active. You cannot understand the cost by looking at the size of the mess; you understand it by looking at what the mess charges you to work around it.

The largest cost: lost engineering capacity

The single biggest cost of technical debt is the engineering time it consumes — capacity you are paying full price for and getting nothing from. This is the interest, made of salaries.

The most-cited figure puts a scale on it. Stripe’s 2018 report, “The Developer Coefficient,” found that developers lose roughly 42% of their time to technical debt and bad code. Sit with that. Across the organizations Stripe surveyed, nearly half of paid engineering capacity went to fighting the codebase rather than extending it — re-deriving behavior the tests should have guaranteed, working around tangled structure, and fixing what brittle code broke. It is the closest thing the industry has to a headline interest rate, and it is enormous.

McKinsey approaches the same cost from the asset side. In an October 2020 analysis, McKinsey estimated that technical debt amounts to 20–40% of an entire technology estate’s value, and that actively managing it down can free up to 50% more engineering time. The two findings agree on the order of magnitude from different directions: debt is not a marginal hygiene cost, it is a structural drag on a large fraction of the whole capability. The “up to 50% more engineering time” figure is the mirror image of the cost — it is the capacity sitting locked behind the debt, available to anyone who pays it down.

Translate that into terms a CFO acts on. A 100-engineer organization is, on these figures, effectively running a fraction of that headcount against the roadmap, with the remainder absorbed servicing debt. No hiring plan recovers that capacity, because every new hire inherits the same tax. The only way to get it back is to pay the debt down. That is the business case in one line, and we develop it fully for leadership in Part 11.

The costs that never reach a budget line

Lost time is the largest cost and the most measurable. It is not the only one. The full bill includes several categories, none of which a finance system files under “technical debt,” which is precisely why the total is chronically underestimated.

Slower time-to-market and missed opportunity. When every change is expensive, the roadmap slows, and the cost is not just the delay — it is the opportunities the business was too slow to reach. This cost is invisible because you never see the revenue you didn’t earn from the feature you couldn’t ship in time. It is real all the same.

Higher defect and incident rates. Debt-heavy code is harder to change correctly, so changes introduce more defects, and defects cost more to diagnose in tangled systems. The cost shows up as incident response, customer churn, and the engineering time pulled off the roadmap to firefight — a second-order interest payment layered on the first.

Security and compliance exposure. Dependency debt — aging libraries and unsupported runtimes — is a cost with a heavy tail. It sits at near-zero for years and then arrives all at once as a critical vulnerability or a failed audit. This is one of the five pressures that pushes systems toward modernization, and its cost is measured in breach risk and compliance findings, not developer hours.

Harder, more expensive hiring and retention. Two costs braid here. Aging dependency debt means hiring for skills the market is abandoning — and the demographics are unforgiving: IBM (reported via Fujitsu, 2020) reports the average COBOL developer is roughly 58, with about 10% of the workforce retiring each year. Meanwhile a debt-ridden codebase is demoralizing to work in; good engineers leave systems where every change is a fight, and their departure is also a knowledge-debt event (Part 3), so the two costs compound.

The cost of delay. This is the one most business cases under-weight, and often the most decisive. Every year debt goes unaddressed, the interest rate climbs as the system grows more tangled, the dependency gap widens, and more of the people who understood the system leave — so the principal of eventual repayment grows too. Delay is not a way to avoid the cost. It is a way to increase it while paying interest in the meantime. We make this argument in full economic detail in the legacy series’ cost of modernization piece; the logic is identical, because unmanaged debt is what turns a system into a legacy system.

Why the cost stays invisible

If the cost is this large, why does it go unmanaged for years? Because of how it is paid. Three properties make technical debt’s cost uniquely easy to ignore.

It is paid continuously, never as a lump sum. There is no invoice, no moment where someone signs off on the total, so there is no event that forces the conversation. A capital expense gets scrutiny; a steady drain on velocity gets normalized.

It is paid diffusely, smeared across every team and every sprint. No one person sees the whole bill. Each engineer experiences “this took longer than it should have” in isolation, and isolated friction does not aggregate into a number anyone reports upward.

It is attributed to other causes. The symptoms — slow delivery, missed dates, attrition, rising defects — all have other plausible explanations. Slow delivery looks like under-staffing. Missed dates look like poor estimation. Attrition looks like compensation. Each symptom gets a wrong diagnosis and a wrong fix, and the underlying debt goes unnamed.

The result is a cost that is simultaneously enormous and invisible — which is the worst combination, because invisibility is what protects it from ever being managed. Making the cost visible is therefore the first real intervention, and it is the subject of the next two parts.

What these figures don’t tell you

Two cautions on the numbers. First, the industry figures here — Stripe’s 42%, McKinsey’s 20–40% — describe aggregate patterns across many organizations. They are excellent for establishing scale and for arguing the general case to a skeptical executive. They are not a measurement of your system, and presenting them as if they were is the kind of overreach that gets a business case dismissed by anyone who checks. Your number could be meaningfully higher or lower.

Second, not all of the slowness in a debt-heavy system is debt. Some of it is the irreducible complexity of a system that genuinely does a great deal, and some apparent “interest” would be paid no matter how the system were built. Attributing every delay to technical debt overstates the case and undermines your credibility when you make it. The disciplined move is to use the industry figures to establish that the problem is large and real, and then to measure your own system before quoting a number anyone will be held to. Our legacy cost calculator is a starting point for the second half — a structured way to put a defensible range on what your own estate costs to carry, rather than borrowing someone else’s average.

Where this leads

We have established the scale of the cost and named where it hides. But a credible case — especially to a CFO — cannot rest on industry averages forever. At some point you have to answer “how much is ours?” with evidence from your own system. Part 5, How to Measure Technical Debt, turns the cost from an estimate into a tracked signal: the qualitative and quantitative methods for measuring debt in a specific codebase, and how to choose ones your team will actually keep using.