Technical debt costs money in one measurable way: the share of engineering capacity spent working around the system instead of extending it. Industry research puts that between 20% and 40% of development budget in organisations carrying significant debt, and Stripe's study of over 300 engineering teams found developers losing roughly a third of their time to bad code. If you cannot state your own figure, you cannot prioritise the work.
This guide covers how to quantify debt in business terms, the metrics that hold up in a budget conversation, how to prioritise what to fix, and how to fund it without asking for a project nobody can see.
Key takeaways
- Debt has a principal and an interest: The fix cost is the principal; the capacity lost every sprint is the interest, and the interest is the argument.
- Benchmark against 15–20%: Average codebases carry that much debt; startups commonly 25–40%; strong teams stay under 10%.
- Not all debt is worth repaying: Debt in code you are about to retire is free.
- Fund it as a standing allocation: A permanent 15–20% of capacity beats a one-off remediation project.
Say what technical debt actually is
Technical debt is the gap between how a system is built and how it would be built if you started today knowing what you now know. Some of it was deliberate and correct, shipping quickly to test a market is a reasonable trade. Some accumulated because requirements changed, dependencies aged, or the people who understood a decision left.
It is not "code I dislike." The distinction matters because engineering preference and business cost are different arguments, and mixing them is why these conversations stall.
The financial metaphor is exact. The principal is what it would cost to fix. The interest is what you pay every sprint until you do. Teams lose these conversations by quoting the principal, which sounds like an expense. The interest is what makes the case.
Quantify it in three numbers
Technical Debt Ratio. Remediation cost divided by the cost of building the system. A ratio of 10% means roughly one hour of fixing for every ten hours of new work. Static analysis tools estimate this automatically, and the absolute number matters less than its direction over time.
Interest rate, or velocity tax. Maintenance hours divided by total development hours, multiplied by the share attributable to debt rather than ordinary support. This is the percentage of your team you are not getting.
Change failure and lead time. How often a release causes an incident, and how long a small change takes from request to production. Both degrade as debt accumulates, and both are already measurable in most teams without new tooling.
| Benchmark | Figure | Source of comparison |
|---|---|---|
| Average codebase debt | 15–20% | Industry code-quality analysis |
| Startup codebases | 25–40% | Speed traded deliberately for structure |
| Strong engineering organisations | Under 10% | Sustained investment |
| Developer time lost to bad code | ~33% | Stripe, 300+ teams |
| Development budget servicing debt | 20–40% | McKinsey, organisations with significant debt |
| Engineer time on debt per month | 2–5 days | Up to a quarter of engineering budget |
Two or three of these, tracked quarterly, are enough. A measurement programme that becomes its own project has failed.
Translate it into a sentence a board understands
"Our technical debt ratio is 22%" moves nobody. The translation is: we have six engineers, we are losing roughly a third of their time to the current system, that is two engineers' worth of salary producing nothing, and it is why the release you asked about in March is still not out.
Attach the delay the business already noticed. Debt becomes fundable at the moment it is connected to a commitment that slipped, not when it is described as a code quality problem.
Prioritise by where change actually happens
Most debt is harmless. Code that works, is not touched and is not going to change costs you nothing regardless of how it is written.
Rank debt by the frequency of change in the area, the business value of what that area supports, the incident history, and the fix cost. High-change, high-value, poor-health areas are where remediation pays. Stable code that nobody edits should be left alone however unpleasant it looks.
The practical filter: look at which files changed most in the last six months, and cross-reference against where incidents originated. That intersection is your list.
Know which debt is not worth repaying
- Code in a system you plan to retire within a year
- Modules that have not been edited in two years and cause no incidents
- Anything where the fix cost exceeds the remaining lifetime value
- Debt in an area about to be rebuilt for other reasons
Saying so explicitly builds credibility for the items that do matter. A list of everything wrong with a codebase is not a plan; it is a complaint.
Fund it as capacity, not as a project
Remediation projects fail predictably. They compete with features, get deprioritised at the first commercial pressure, and produce nothing visible while they run.
The approach that works is a standing allocation, commonly 15–20% of each sprint, spent on the areas the prioritisation identified. It requires no separate approval, produces continuous improvement, and stops the debate recurring every quarter.
Pair it with a rule that new work leaves the area it touched no worse than it found it. Most debt accumulates through small compromises, and most of it can be prevented the same way.
Prevent the debt you are about to create
Some debt is a deliberate, sound trade. The failure is taking it without recording it.
When a shortcut is chosen, write down what was done, why, what it will cost to undo, and what condition should trigger revisiting it. Undocumented shortcuts become permanent because the reasoning leaves with the person who made the decision.
The largest preventable source is unclear requirements. Software encodes rules; if the rules were never settled, the code encodes a guess, and every subsequent change works around it. Standardising an unstable process before building saves more than any code-level discipline.
Review it on a cadence, not on frustration
Put debt on a quarterly review with the same three numbers each time. Rising ratio with stable delivery is tolerable; rising ratio with lengthening lead time is the signal to act.
Deciding this on a schedule prevents the two failure modes: never addressing it until a rewrite feels inevitable, and addressing it whenever an engineer is most frustrated rather than where the business is actually losing time.
Related guides
- The same trade-off from the other side appears in AI Workflow Automation: Use Cases, Risks, and Roadmap.
- If the budget conversation comes first, start with Admin Dashboard Development: Features, Architecture, and Cost Drivers.
Should Technical Debt: Business Risks, Examples, and Prioritization become a modernisation programme rather than a series of fixes, Discuss Your Modernization Plan.
Ali Boran Gazel