ยท 6 min read
Technical debt: what it costs you per month.
Debt you cannot price, you cannot manage. The way out of every stalled technical-debt discussion is to turn it into a monthly number the board can read.
What does technical debt cost per month?
For a typical software company, technical debt consumes 20 to 40 percent of engineering capacity. At a 20-engineer organisation in Belgium, with a fully loaded payroll around EUR 2 000 000 a year, that is EUR 35 000 to EUR 65 000 a month before counting the infrastructure it wastes or the incidents it causes. The exact share matters less than this: it is a recurring monthly bill, and in most companies nobody has ever written it down.
Where the monthly bill hides
| Form of debt | How it bills you | Typical order of magnitude |
|---|---|---|
| The velocity tax | Every feature routed around the same fragile modules takes 1.5 to 3 times longer | 20 to 40 percent of engineering capacity |
| The incident load | Defects and outages from the same known weak spots, plus the interruptions they cause | 1 to 3 engineer-days a week at mid-size |
| The infrastructure it wastes | Duplicate storage, oversized clusters, pipelines nobody dares touch | Often 10 to 25 percent of the cloud bill; in one engagement a single pipeline billed EUR 12 000 a month |
| The key-person premium | Only one person can touch the module, so their calendar is the roadmap | Invisible until they resign, then a quarter |
| The hiring drag | Good engineers read the codebase in week one and quietly shorten their tenure | Shows up as attrition, priced at 6 to 9 months of ramp-up per departure |
How to measure it without a framework
Skip the code-quality scores. They measure what tools can count, not what the business pays. Instead, write the debt ledger: the ten concrete debts your engineers actually complain about, each with two numbers.
- The monthly price of leaving it. Hours lost, incidents caused, infrastructure billed, multiplied into euros. Estimates are fine; the point is the order of magnitude.
- The one-off price of fixing it. In engineer-weeks, converted at your loaded cost, roughly EUR 2 000 a week per engineer in Belgium.
Anything that cannot be priced this way is usually preference dressed up as debt. "The framework is old" is not a debt; "upgrading is blocked, so every security patch costs a week" is, and it has a number.
When do you pay it down?
When the monthly price beats the one-off price within a year or so. A debt that costs EUR 12 000 a month and EUR 60 000 to fix is a five-month payback; that is not a technical discussion, it is an ordinary investment decision. Two exceptions keep the ledger honest: debt in code that is about to be replaced costs nothing to keep, and debt that carries key-person or security risk can justify fixing ahead of its payback.
Why this framing changes the conversation
Because it moves the debate from taste to money. Engineers stop having to plead for "refactoring time" and the board stops hearing a hobby request. The ledger also cuts the other way: half the items engineers nominate turn out to cost less monthly than fixing them would, and saying so out loud buys credibility for the half that matters. Pricing the ledger is part of what the 3-week diagnosis produces; the cloud-bill portion has its own post in reducing AWS costs.
The percentages reflect what I find across engagements; your ledger will disagree in the details, which is exactly why it should exist.