How much is your tech debt costing you?

Everything starts from the average annual gross salary you enter. I multiply it by 1.42 to get an employer cost: 42% in charges, an order of magnitude for a salaried executive in France. It is an assumption, and the advanced settings let you replace it with your own rate.

That cost is then spread over 1,820 hours, or 52 weeks of 35 hours. Holidays and public holidays are not deducted: the hourly cost is lower than reality, which keeps the estimate conservative. With a €55,000 gross salary, that gives €78,100 in employer cost and about €43 an hour.

• Annual employer cost = gross salary × 1.42.
• Hourly cost = employer cost ÷ 1,820 hours.
• Team cost = employer cost × number of developers.

Each line is lost time, valued at the hourly cost or expressed as a share of the team’s annual cost. The default durations are field assumptions, not measurements: I write them down here so you can compare them with your team.

• Production bugs: bugs per week × 4 hours to fix × hourly cost × 52 weeks. The 4 hours can be adjusted.
• Deployment friction: hours lost per developer per week × team size × hourly cost × 52 weeks. The assumption follows the release pace: 0.5 h for daily, 1.5 h for weekly, 3 h for biweekly, 5 h for monthly.
• Insufficient testing: 0.25% of the team’s annual cost per coverage point below the 60% threshold, capped at 15%. Details follow.
• Manual processes: manual hours per week for the team × hourly cost × 52 weeks.
• Codebase age: 3% of the team’s annual cost per year beyond 3 years. A 4-year-old codebase counts for 3%, a 15-year-old one for 36%.
• No CI/CD: 2 hours lost per developer per week × team size × hourly cost × 52 weeks, only if you answer no.

This line estimates rework: the time spent fixing, rechecking or redoing a change that tests would have secured. Each coverage point below the threshold costs 0.25% of the team’s annual cost. At 40% coverage, the 20-point gap gives 5%; at 0%, it gives 15%.

It is an assumption, not the result of a study. Coverage counts the lines run by tests, not how well critical paths are protected: a team at 30% with well-placed tests can be better protected than another at 70%. So that a single figure does not inflate the total, the line is capped at 15% of team cost, whatever threshold you choose.

The 60% threshold can be adjusted. At 0, the line disappears: it is the simplest way to rerun the calculation without this assumption.

Every line is paid time. So the calculator also expresses the total in 7-hour developer days and as a share of the team’s annual capacity. With the default answers, for 5 developers at €55,000 gross, the estimate reaches €85,910 a year: 286 developer days, or 22% of the team’s capacity.

The employer charges rate changes the euros, not this share: it raises the team cost and the debt cost in the same proportion.

The risk level takes the higher of two criteria: the share of the team’s annual cost and the absolute amount. The amount raises the risk of a large team even when the share stays modest, because €150,000 a year is already a leadership decision. These thresholds are reading guides I set, not a standard.

• Low: up to 8% of team cost and up to €60,000 a year.
• Medium: above 8% or €60,000.
• High: above 15% or €150,000.
• Critical: above 25% or €300,000.

If you know what share of the team’s time goes to maintenance (fixes, updates, refactoring and technical support for the existing product, planned or not), the quick mode applies it directly to the team’s annual cost, calculated as above. For 5 developers at €55,000 gross and 30% maintenance: 30% of €390,500, that is €117,150 a year and 390 developer days.

It is not the same calculation as the detailed mode. The detailed mode rebuilds, line by line and from assumptions, the time the debt takes. The quick mode starts from time you have observed, but that time also contains healthy maintenance: fixing an isolated bug, updating a dependency, following a regulatory or API change. Its result values the time reported. It measures neither the total cost of debt nor an upper limit: debt can also slow down new features, which are excluded from this share.

I add neither an “opportunity cost” nor a multiplier. What the team did not build during that time has a value, but it depends on your product and your market: a fixed coefficient would pass it off as a measurement.

To put a declared share in context, the only published reference I could verify is an average. In Stripe’s The Developer Coefficient survey (2018, with Harris Poll), the developers surveyed put the average time spent on maintenance at their company (bad code, errors, debugging, refactoring, modifying) at 17.3 hours a week, out of an average 41.1-hour week. From these two averages, I derive a share of about 42% myself. It is not a healthy threshold, and I do not set a threshold in place of a standard that does not exist.

• Maintenance cost = declared share × team annual cost.
• Developer days = cost ÷ hourly cost ÷ 7 hours.
• Share of capacity = the declared share, since everything is paid time.

Sources

• Stripe, The Developer Coefficient, September 2018 (PDF) (opens in new tab)

In 2009, Martin Fowler proposed classifying technical debt along two axes: deliberate or inadvertent, prudent or reckless. Deliberate and prudent is the team that ships sooner knowing the price it will pay later. Deliberate and reckless is “quick and dirty” chosen because people believe they cannot afford good design. Inadvertent and reckless is the team that ignores design practices and takes on debt without knowing it. Inadvertent and prudent is what even an excellent team discovers: as it goes, it understands what the design should have been.

For Fowler, this last case is inevitable and should be expected: even the best teams accumulate it as a project goes on. A non-zero cost is therefore not, in itself, the sign of a fault. He also notes that prudent debt in rarely touched code may not be worth repaying if its interest stays small.

The calculator estimates the interest: the time the debt takes each year, whatever its origin. It does not know which quadrant the debt was born in. The same week of fixes can come from a shortcut accepted before a deadline or from a design nobody knew could be better. Finding out takes the history of decisions: tickets, discussions, architecture decisions and the team’s memory.

• What the calculation estimates: the annual cost of the interest, in euros and in team time.
• What it does not say: whether the debt was deliberate or inadvertent, prudent or reckless, nor what repaying it would cost.
• What the quadrant adds to the reading: a cost carried by code the roadmap touches every week weighs more than the same cost in a rarely changed area.

Sources

• Martin Fowler, Technical Debt Quadrant, 14 October 2009 (opens in new tab)

The result helps order a discussion; it does not replace a measurement. To measure, you need to look at the code, the incidents and the backlog.

• Lines add up but can overlap: frequent bugs and low coverage sometimes describe the same lost time, as do missing CI/CD and deployment friction.
• The default durations (4 h per bug, friction hours, 2 h without CI/CD, 3% per year of age) are field assumptions, not published measurements.
• Age is not debt: a well-maintained old codebase costs less than the model says, and a recent codebase built in a rush can cost more.
• The model counts neither incidents experienced by customers, nor lost revenue, nor a developer leaving. It estimates lost capacity, not the whole risk.
• For a small team with high answers, the total can exceed the team’s capacity: a sign that the lines overlap.

• Check technical debt cost assumptions