Technical debt cost: you have already paid for the hours

A fictional team of six developers, €468,600 a year in employer cost, of which the calculator attributes €182,196 to technical debt. Nobody saw it leave: no invoice carries it. Ask a founder what their debt costs and they will look for that invoice. Removing the debt does not take a single euro off payroll, and they pay for it all the same, every week, in the place they examine least: their team’s hours.

That amount represents a share of capacity: a share of hours already paid for that goes into fixes, waiting around releases, tasks redone by hand, the caution demanded by code nobody dares touch any more. That share is invisible because nobody counts it. That is what the technical debt cost calculator is for: making it visible, in euros because that is the language of a board meeting. Not producing an exact figure. It covers code, tooling and delivery; the five faces of technical debt are a reminder that organisational and security debt cost you elsewhere.

The calculation starts from two numbers you already know: team size and a developer’s average gross annual salary. The salary is multiplied by 1.42 to approximate employer cost, an order of magnitude based on the French Urssaf Mon-entreprise simulator for a permanent managerial contract, adjustable. Divided by 1,820 hours, 52 weeks of 35 hours, it gives an hourly rate; multiplied by the number of developers, what the team costs you a year. Each item then estimates how many hours go into work the debt imposes. The result is lost capacity, not extra spending. A team that recovers those hours does not cost you less. It can put those hours towards the roadmap you have been waiting for.

Is there a normal share? The only public reference I have been able to verify is a self-reported average: in The Developer Coefficient, a 2018 Stripe survey with Harris Poll of more than 1,000 developers, respondents estimated they spent 17.3 hours a week on maintenance, out of an average 41.1-hour week. About 42%, and that ratio is my calculation, not a figure from the study. It is not a healthy threshold; it is what developers say they live with.

A number whose formula is hidden is worth nothing in front of a board. Here is the engine, constants included.

Item	Formula
Production bugs	bugs per week × 4 h to fix × hourly rate × 52 weeks
Deployment friction	hours lost per developer per week × number of developers × hourly rate × 52
Missing tests	max(0, coverage threshold − coverage in points) / 100 × 25% × team annual cost, capped at 15% of that cost
Manual processes	manual hours per week for the team × hourly rate × 52
Codebase entropy	max(0, age in years − 3) × 3% × team annual cost
No CI/CD	2 h per developer per week × number of developers × hourly rate × 52

Friction runs from 0.5 hours per developer per week for daily releases to 5 hours for monthly. The 4 hours per bug, the 42% employer charges rate and the coverage threshold, set to 60% by default, can be adjusted; the 15% cap does not move. The total is compared with the team’s annual cost: moderate risk above 8% or €60,000, high above 15% or €150,000, critical above 25% or €300,000.

Fictional team, real engine. Six developers on an average gross salary of €55,000 a year, so €78,100 of employer cost each, €468,600 for the team, an hourly rate of €42.91. Releases every two weeks, no CI/CD, three production bugs a week, five hours of manual tasks, 30% test coverage, a six-year-old codebase. The picture may look familiar; the figures are still assumptions.

Item	Calculation	Annual cost
Production bugs	3 × 4 h × €42.91 × 52	€26,777
Deployment friction (fortnightly level)	3 h × 6 × €42.91 × 52	€40,166
Missing tests	30 / 100 × 25% × €468,600	€35,145
Manual processes	5 h × €42.91 × 52	€11,157
Codebase entropy	3 × 3% × €468,600	€42,174
No CI/CD	2 h × 6 × €42.91 × 52	€26,777
Total		€182,196

The total is 38.9% of the team’s annual cost, classified as “critical” by the model. Converted into hours, it represents about 4,250 hours a year, displayed as 607 developer days: the arithmetic equivalent of 2.3 of the six positions. That does not mean you can return 2.3 positions to the roadmap. Before calling it lost capacity, you need to check what each item counts, remove overlaps and distinguish necessary work from avoidable work. The model tells you where to look. It does not know what is in your code.

The heaviest line in the example is also the least measurable. Three percent per year beyond three years is a convention, not an observation: a well-structured, tested six-year-old application pays the same as a six-year-old application where every change breaks another flow. Four hours per bug prices a label typo and a billing error identically. And the calculation ignores what often costs the most: the customer lost after an incident, the contract signed late, the forgotten access that exposes data. Waiting for an approval, the organisational debt kind, only shows up there as a shadow.

So do not budget on this number. Check it against a few weeks of reality: the fixes shipped in the period, each with its time spent diagnosing, changing, reviewing and deploying, separated from calendar waiting. That average replaces the model’s four hours. Then run several conservative assumptions through the calculator. If the same item stays on top, you have your priority. If it changes rank at the slightest variation, you do not yet have enough data to commit a budget.

The model adds six cost items. In your team, their boundaries overlap: manually deploying a fix could appear under bugs, manual processes and missing CI/CD. Adding all three produces a bigger number. It does not create three hours in the developer’s day.

I would start with a small intervention log, linked to tickets, over a few weeks. Take a fictional example, separate from the six-developer team above: a fix reaches production two days after the issue is reported. Here is the work actually done in this example.

Work	Time spent
Diagnosis by one developer	1 h
Changes and tests by that developer	2 h
Review by another developer	0.5 h
Manual deployment by the first developer	0.5 h
Total work	4 h

At the illustrative €42.91 hourly rate used above, that represents €171.64 of capacity consumed. Two calendar days describe the customer’s wait; four hours describe the team’s work. The half-hour deployment is already part of those four hours. If you also tag it as delivery friction to investigate the cause, keep that second classification out of the total.

Those four hours are not automatically all technical debt. Fixing a defect involves necessary work; you still need to identify what rework, dependencies or avoidable manual steps add to it. Record each intervention’s suspected cause, the people involved and waiting time separately. One intervention, one time record, potentially several causes. You can then compare an estimate with work records, without presenting the calculator’s total as an invoice or promising that refactoring will recover every hour.

In front of €182,196, a founder’s reflex is to ask for a repayment plan. That is the wrong question: debt is not repaid in one block; it is renegotiated item by item, in an order that is not the order of the amounts.

When incidents absorb the team, I first look at what needs stabilising. At Gridky, where I was Head of Engineering, that work took the form of a feature freeze of a month and a half. The CTO and the CEO had agreed the schedule, the whole team worked on fixes and any code touched had to be tested. When feature work resumed, the team was reunited and my manual triage of exceptions, every morning, no longer had a reason to exist. No line in the calculator will tell you to do that. The calculator has not seen your Slack.

Minimal CI follows: a reproducible build, tests on the critical paths, checks before a change is merged. In the example, CI brings the total from €182,196 to €155,419, and weekly releases bring it to €135,336; those are differences in the model, not a measured gain. Automation comes last, on the two or three most expensive repetitive tasks: here, the smallest item, €11,157. It comes after delivery, unless those tasks are the thing delaying releases.

The calculator’s number gives the leadership team a hypothesis to test: where do the team’s hours go, and how much of that work could be avoided? Run it with your real numbers, then spend a few weeks with the team checking the two heaviest items. To decide what to tackle, compare the time lost each week with the work needed to remove its cause. Tracing those items to specific causes is the work of the five-day technical and organisational diagnostic; the page on architecture and technical debt describes the situations where I step in.