Technical debt has been called many things: a credit card balance, a cluttered garage, a slow-motion avalanche. Every metaphor has the same problem. None of them produce a number.

Here is a number.

The baseline

A software engineer in Europe, fully loaded — salary, social charges, equipment, tooling, office, management overhead — costs around €450 per day. This figure varies from roughly €250 in eastern markets to €900 in Zurich, but €450 is a reasonable European average.

A team of ten engineers working twenty days a month costs €90,000 per month. That is the budget you are already spending. The question is: what percentage of it is being spent on debt?

Three costs, not one

Technical debt shows up in your month-to-month budget in three distinct ways.

1. Firefighting cost

This is the time your engineers spend reacting to bugs instead of building features. You can measure it directly from your commit history: what percentage of commits start with fix:, hotfix:, bugfix:, or match similar patterns?

If 18% of commits are bug fixes, and your team costs €90k/month, your firefighting cost is €16,200/month. Or roughly €195k/year.

2. Debt servicing

This is the time spent maintaining the debt without reducing it: configuration churn, dependency updates, superficial refactoring that doesn't change the underlying structure. It's real work. It ships. It keeps the lights on. But it does not move the product forward.

Classify your non-feature commits (everything that isn't a clear feat:). For most teams, debt servicing runs between 15% and 30% of capacity.

3. Recovery investment

This is the one-time cost to actually clean up. It is not a recurring line item. It is a budget you approve once, spend over a quarter or two, and then reap the returns from for years.

A rough formula:

Critical hotspots: ~2 days of engineering each
Knowledge silos: ~1 day each (pairing, documentation, rotation)
Dead code: ~30 minutes per file

For a mid-sized codebase, recovery investment often lands between €30k and €100k. It is the most important number because it tells you what you need to spend to stop paying the other two.

Why this is different from SonarQube

SonarQube and similar tools tell you where your code has problems. They give you a line number, a rule identifier, and a severity. That's useful — but it doesn't tell you what the code costs.

A file with zero SonarQube issues can still be a disaster if it is changed every week by three different developers and generates half of your bugs. A file flooded with SonarQube warnings can be harmless if nobody touches it and it works fine.

Cost lives in behavior, not in syntax. And behavior is recorded in your Git log, not in your abstract syntax tree.

The number that unlocks the conversation

When you walk into a budget meeting with "our platform has a cyclomatic complexity problem," people nod and change the subject.

When you walk in with "our current codebase is costing us €21,300 per month in firefighting and debt servicing, and a €58,000 cleanup investment would pay back in eleven months," people start asking follow-up questions.

The conversation you actually want is the second one. The first one makes you feel heard but changes nothing.

Technical debt in 2026 is expensive. But it is also, for the first time, measurable. We have enough commit history, enough behavioral signal, enough computing power to give engineering leaders a number they can defend.

Use it.