Technical debt
Your engineers say "technical debt". Your accountant sees nothing.
Technical debt typically costs a software company 20 to 40 percent of its engineering capacity, and a technical debt review turns that into a monthly price per item, so paying it down becomes a business decision instead of an engineering complaint.
Debt that never appears on a P&L never gets paid down. The fix is not a rewrite. It is a price: what each debt costs you per month, in engineer hours, cloud spend, incidents and missed releases, next to what it costs once to fix.
Where the monthly bill hides
Debt rarely shows up as one line. It bills you in 5 places, and only one of them is on an invoice.
- The delivery tax. Every feature routed around the same fragile modules takes 1.5 to 3 times longer than it should.
- The incident load. Outages from the same known weak spots, plus the interruptions they cause. At mid-size, 1 to 3 engineer-days a week.
- The infrastructure it wastes. Duplicate storage, oversized clusters, a pipeline nobody dares touch. In one engagement a single pipeline billed EUR 12 000 a month.
- The key-person premium. Only one person can change the module, so their calendar is the roadmap. Invisible until they resign.
- The hiring drag. Good engineers read the codebase in week 1 and quietly shorten their tenure.
Technical debt has a monthly cost works through each form with orders of magnitude.
Putting a number on it
Skip the code-quality scores. They measure what tools can count, not what the business pays. Write the debt ledger instead: the 10 concrete debts your engineers actually complain about, each with 2 numbers. The monthly price of leaving it, in hours lost, incidents and infrastructure. And the one-off price of fixing it, in engineer-weeks at your loaded cost.
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. Then the rule is simple: pay a debt down when its monthly price beats its one-off price within about a year. A debt that costs EUR 12 000 a month and EUR 60 000 to fix is a 5-month payback. That is an ordinary investment decision, not a technical discussion.
Who this is for
Founders, CEOs, CFOs and owners who keep hearing "technical debt" as the reason for slipping dates and rising bills, and cannot judge whether it is real. Scale-ups with 15 to 120 engineers, and owner-led companies with 5 to 40 people in and around software, or an agency building it for them.
- Every estimate arrives with "but first the module needs a rewrite".
- Engineers ask for refactoring time and you have no way to judge the request.
- The same incident comes back every quarter.
- One person is the only one who dares touch a core system.
Who it is not for
- You want a rewrite approved. The review often concludes against one, and says so.
- You want a code-quality score for a slide. A tool does that for less.
- The product is about to be retired. Its debt costs nothing to keep.
- You want someone to do the refactoring. Your engineers do the work; I price it and sequence it.
When people call
- A rewrite proposal landed on the table with a 9-month estimate and no business case.
- Delivery slowed down while the team grew.
- The lead developer who understands the old system has handed in notice.
- An ERP, a platform or a customer portal is up for a rebuild, and nobody can say what the old one costs to keep.
- A buyer or an investor is about to look under the hood. That is technical due diligence, from the other side of the table.
- The cloud bill keeps rising, and part of it is an architecture nobody chose on purpose. See reducing cloud costs.
How a technical debt review runs
The debt ledger is part of the 3-week diagnosis: EUR 9 500, fixed, agreed before the work starts.
| When | Work |
|---|---|
| Week 1 | Interviews with every engineer and with whoever manages the suppliers. 6 months of pull requests, incidents and lead times read. The cloud and supplier bills. A first list of the debts people actually name. |
| Week 2 | Each debt priced: what it costs per month to leave, what it costs once to fix, checked against the delivery data rather than opinion. Preference separated from debt. |
| Week 3 | The ranked ledger, a paydown sequence, the items to keep on purpose, and a written report. A working session with you and the engineering lead. |
After the diagnosis
The team pays the debt down inside normal delivery, ranked by payback, not in a separate refactoring quarter that never ends. If you want the sequence held, I stay on for 1 to 2 quarters, a few days a month or 1 to 2 days a week depending on the size of the team.
How it ends
The ledger gets an owner, usually the engineering lead, and a quarterly refresh on the calendar. New debt goes on it with its 2 numbers before anyone argues about it. When the ledger runs without me, I leave.
What it costs
The diagnosis is EUR 9 500, fixed. Any follow-on time is billed at day rates in the normal Western European band of EUR 1 000 to EUR 1 600, invoiced monthly. No equity, no success fee. If the review finds debt that is cheaper to keep than to fix, that goes in the report too, which is one reason the fee is not tied to what gets fixed.
What the ledger has produced
- Cloud bill down 42 percent. A pipeline storing every intermediate result 3 times billed EUR 12 000 a month. Once that was written down, fixing it stopped being a technical debate. From EUR 74 000 to EUR 43 000 a month in 5 months, no layoffs, no re-platforming.
- 45 engineers to 22. Series B SaaS, releases slipping, 2 platform teams maintaining infrastructure for customers the company no longer sold to. Weekly releases again after 4 months, payroll from EUR 4 000 000 to EUR 2 000 000.
- The portal shipped in 11 weeks. Owner-led SME, 60 people, eighteen months of supplier delay. Two-thirds of the portal already existed; the rest was blocked on decisions, not code. EUR 180 000 a year off the agency bill.
A debt review, a code-quality tool, or a refactoring budget
| Option | What it does well | Where it stops |
|---|---|---|
| A code-quality tool | Counts complexity, duplication and outdated dependencies. Cheap, continuous, useful for engineers. | It measures what tools can count, not what the business pays. A red score does not say which debt costs money. |
| A fixed refactoring budget | Gives the team a share of every sprint and ends the debate for a while. | Nobody checks what the time bought. It drifts to the debt engineers find most annoying, not the most expensive. |
| A priced debt review | A monthly price and a fix cost per debt, ranked by payback, with the items to keep named. | It works in orders of magnitude, not to the euro. It needs an owner to stay current. |
The three combine well. The review sets the ranking, the budget funds it, and the tool keeps new debt visible.
Where it fits
The same lens runs the cloud cost review and technical due diligence. Same method, different buyer. It sits under platform cost and technical debt in the overview of services, and it is one of the outputs of the 3-week diagnosis. For the cloud side of the ledger, read reducing AWS costs is an ownership problem. For owner-led companies whose debt sits with a supplier, the SME that became a software company by accident describes the pattern.
Frequently asked
What does technical debt cost per month?
For a typical software company, technical debt consumes 20 to 40 percent of engineering capacity. At 20 engineers 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 the infrastructure it wastes or the incidents it causes.
How do you put a number on technical debt?
Every debt item that matters shows up somewhere measurable: the feature that takes 6 weeks instead of 2, the incident that repeats quarterly, the system only one person dares touch, the cloud bill inflated by an architecture nobody chose on purpose. Reading it out of the delivery data and the bills turns it into a monthly cost, in engineer hours, cloud spend, and missed releases.
What is a technical debt review?
A structured read of the codebase, the delivery data and the bills that ends in a ledger: each debt with a monthly cost of leaving it and a one-off cost of fixing it, ranked by payback. It is part of the 3-week diagnosis, at EUR 9 500, fixed. It ends with a written report, not a slide of scores.
What changes once technical debt is priced?
The conversation changes owner. It stops being an engineering complaint and becomes a line the CEO can rank: this item costs EUR 15 000 a month and takes six weeks to retire, that one costs EUR 2 000 and can wait. Some debt is worth keeping. The report says which, in writing, so the decision is the business's and documented.
When should you pay down technical debt?
When the monthly price of leaving it beats the one-off price of fixing it within a year or so. Debt in code that is about to be replaced costs nothing to keep. Debt that carries key-person or security risk can justify fixing ahead of its payback.
Is a rewrite the answer to technical debt?
Rarely. A rewrite swaps known debt for unknown debt and stops delivery for months. Most ledgers show a handful of items that pay back within a year and can be fixed inside normal delivery. A rewrite is right when the old system blocks the business and the ledger shows no cheaper way out.
Who does the work after the review?
Your own engineers, or your supplier under a rewritten scope. I don't write production code. I price the debt, set the sequence with you, and hold it if you want me to, until the engineering lead owns the ledger.