Skip to content

Technical Debt Calculator

Priced as interest, the argument becomes arithmetic.

Work out Technical Debt. Priced as interest, the argument becomes arithmetic. States the assumption instead of hiding it.

Written and maintained by Mohit PatelLast checked August 4, 2026How we build these

Workarounds, slow builds, flaky tests, fear of touching it

% a year

Annual interest on this debt

82,800

9,000 to pay it down · 1.3 month payback

Hours lost across the team each week24
Hours a year1,104
Annual interest82,800
Principal — cost of fixing it9,000
Payback period1.3 months
Effective annual interest rate920%
Five years ignored, growing 20% a year616,164
Five years having fixed it9,000
Net five-year saving607,164
VerdictPays for itself in under a quarter — do it now

Treating debt as interest rather than as a metaphor turns an argument into arithmetic. The interest is real recurring cost — 24 hours a week the team spends working around something rather than on the product — and the principal is what clearing it would take. An effective rate of 920% would be refinanced immediately if it were an actual loan. Both figures are estimates and the hours lost is the softer of the two, so measure it for a fortnight rather than guessing. The point is not the precision — it is that the cost of doing nothing becomes a number that can be compared against the cost of doing something.

How the Technical Debt Calculator works

Technical debt priced as interest and principal: the hours the team loses every week, against what clearing it would cost, with a payback period and a five-year comparison. Both figures are estimates, and framing it this way turns an argument into arithmetic.

Also known as: technical debt · tech debt · refactoring roi · should we refactor · cost of tech debt · debt interest · rewrite business case · legacy code cost · maintenance burden

Interest and principal, not adjectives

The interest is the hours the team loses every week to the debt: workarounds, slow builds, flaky tests, the caution that surrounds code nobody trusts. It recurs whether or not anyone acts on it.

The principal is what clearing it would cost. Both are estimates, and putting them side by side turns a recurring argument about code quality into an arithmetic comparison that a budget conversation can actually use.

Six people losing four hours a week at a £75 fully loaded rate is around £83,000 a year. Against a fifteen-day fix costing £9,000, that is a payback under two months — an effective interest rate above 900%, which would be refinanced immediately if it were an actual loan.

Not all debt is worth paying down

Debt in code nobody touches costs nothing to carry. It may be ugly, outdated and embarrassing, and if it imposes no interest then paying the principal is a pure loss.

This is why the interest matters more than how bad the code looks. The areas that generate the most complaint are frequently not the areas that generate the most lost time, and measuring settles it where opinion does not.

A payback measured in years is a legitimate reason to leave something alone, or to fix it incrementally alongside feature work in the same area. The calculation is as useful for declining a rewrite as for justifying one.

Measuring the interest rather than guessing it

Ask the team to track time lost to workarounds, waiting for builds and re-running flaky tests for a fortnight. The total is usually higher than anyone estimated, and it lands in places nobody predicted.

The exercise also resolves disagreements about where the debt is, because it replaces a discussion about which code is worst with data about which code is most expensive.

The growth rate is the other input worth thinking about. Some debt is stable and some accelerates as workarounds accumulate on workarounds — and compounding is what turns a tolerable annual cost into an intolerable five-year one.

Where to go next

The Technical Debt question rarely arrives on its own. These are the ones that usually come with it:

Frequently asked questions

How do I quantify technical debt?

Measure the interest, not the mess. Count the hours the team loses each week to workarounds, slow builds and fear of touching the code, and price them at fully loaded cost.

How do I decide whether to refactor?

Compare the annual interest against the cost of paying it down. A payback period under a year is a straightforward case; a payback measured in years usually means doing it alongside related work instead.

Why call it interest?

Because it recurs whether or not you act, and it grows if the debt does. The metaphor only becomes useful when both sides are actual numbers rather than adjectives.

How do I measure hours lost?

Track it for a fortnight rather than guessing. Ask people to note time spent on workarounds, waiting for builds, and re-running flaky tests — the total is usually higher than anyone estimated.

Is all technical debt worth fixing?

No. Debt in code nobody touches costs nothing to carry, which is why the interest matters more than how bad the code looks. A payback of several years is a legitimate reason to leave it alone.

Should refactoring be a separate project?

Usually not. Debt paid down as part of feature work in the same area is easier to justify and easier to schedule; a standalone rewrite is the highest-risk way to spend the principal.

What counts as technical debt?

Anything where a past shortcut makes present work slower — missing tests, duplicated logic, a framework nobody understands, a build that takes twenty minutes. Code that is merely old or unfashionable is not debt.

Is deliberate technical debt ever right?

Frequently. Shipping something imperfect to learn whether it matters is a sound trade, and it is only debt if the shortcut is recorded and the interest is watched. Unacknowledged shortcuts are the problem.

How do I convince management to fund a refactor?

With this arithmetic rather than adjectives. An annual interest figure and a payback period are the language a budget conversation runs in; 'the code is bad' is not.

Should debt be paid down all at once?

Usually not. Incremental payoff alongside feature work in the same area is lower risk and easier to schedule, and a standalone rewrite is the most dangerous way to spend the principal.

How fast does technical debt grow?

It compounds, because workarounds built on workarounds get harder to remove. The growth rate is an input here because it varies enormously — some debt is stable, some accelerates sharply.

What if the team disagrees about where the debt is?

Measure it. Ask everyone to track hours lost for two weeks and the disagreement usually resolves itself, because the areas actually costing time are rarely the ones people complain about most.

Put this calculator on your own site

Free to use, on any site, commercial or not. Paste this where you want it to appear. It is a plain iframe, so it works in WordPress, Squarespace, Wix, Webflow, Ghost and anything else that accepts HTML.

The one-line version
<iframe src="https://www.thecalclibrary.com/embed/technical-debt-calculator" width="100%" height="640" style="border:1px solid #e2e8f0;border-radius:12px" loading="lazy" title="Technical Debt Calculator"></iframe>
<p style="font:13px/1.5 system-ui,sans-serif;margin:6px 0 0;color:#64748b">Powered by <a href="https://www.thecalclibrary.com/technical-debt-calculator" style="color:#64748b">Technical Debt Calculator</a> from The Calc Library</p>

The only condition is that the credit line below the frame stays in place. That one line is what pays for the tool being free — it is how anyone else finds it.

Related calculators