Developers talk about technical debt like the weather — omnipresent, intangible, nobody's fault. A CFO rightly tunes that out. The language both sides understand is euros per month.
Three measurable components of debt
One: slower development — if a feature that should take three days takes six in tangled code, the difference is a direct cost. Two: incidents — firefighting hours times the hourly rate, plus revenue lost during the outage. Three: onboarding — how many weeks a new developer needs to become productive. In a healthy project two, in an indebted one eight.
How to work with the number
Once you know the debt costs €8,400 a month, a €35,000 refactoring stops being “the developers' wish” and becomes an investment with a 4-month payback. The opposite conclusion is just as legitimate: leave the debt in a module nobody changes — repaying debt that slows nobody down is a luxury.
Good debt vs. bad debt
Not all technical debt is a problem. A deliberate shortcut that got your product to market sooner is good debt — you repay it once the hypothesis holds. Bad debt is the unconscious kind: chaos nobody planned that slows every change. Maturity is not “zero debt”, but knowing which debt you carry and why.
How to prevent debt, not just repay it
The cheapest debt is the one that never appears. Code review, tests and clear module ownership cost a few percent more during development and save multiples in maintenance. That is why quality KPIs belong in the contract alongside deadline and price. Refactoring is the cure; discipline during development is the prevention — and prevention is always cheaper.
We quantify technical debt as part of Audit 48. Not because we want to sell refactoring — half of our clients are told afterwards not to refactor.