What actually counts as technical debt?

Anything in the code, architecture or tooling that makes future change more expensive than it needs to be: shortcuts taken under deadline, missing or unreliable tests, outdated dependencies, duplicated logic, undocumented behaviour, and slow build and deployment pipelines. The last of these is often excluded from definitions, yet it is frequently the largest measurable drag on a team.

Why express debt as capacity instead of money?

Because capacity is the currency delivery plans are written in and money is not. A cost figure invites a methodology argument, since the salary was going to be paid anyway. Saying a ten person team is delivering like a six person team directly contradicts every forecast built on headcount, which is a much harder statement to dismiss.

How do I measure the percentage of time lost to rework?

Use ticket categories if you separate maintenance from feature work, run an anonymous team survey, or sample a few weeks of work explicitly. All three give different answers, usually within ten to fifteen percentage points of each other, so take the range rather than a single figure and state which method you used.

Why 1,840 hours a year and not 2,080?

2,080 is 52 weeks at 40 hours and assumes nobody takes leave, is never sick and never has a public holiday. Using it understates the true cost of an engineering hour and overstates how much capacity a team has. 1,840 allows roughly six weeks a year for leave, holidays and sickness, which is closer to reality in most markets.

Is all technical debt worth repaying?

No. Debt in code that nobody changes costs nothing, so repaying it is effort with no return. Target the debt on the paths your team touches most frequently, which is where the drag actually accrues. A simple way to find it is to overlay change frequency on complexity and work on what scores high in both.

How much time should a team spend on remediation?

A commonly used standing allocation is 15 to 20 per cent of every iteration, treated as non-negotiable rather than the first thing cut when a deadline approaches. A standing allocation survives priority changes far better than a special project, and it stops debt compounding between the occasional large clean-up efforts.

Technical Debt Cost Calculator

Works anywhere

Expresses technical debt as lost team capacity rather than a notional dollar figure, combining time spent working around existing code with time blocked waiting on builds. A ten developer team losing a quarter of its time to rework and 45 minutes a day to pipelines is running at 3.44 developers short.

Enter your values

Developers on the team

Engineers who write or review code. Exclude managers and product roles who do not ship changes.

Average base salary

Base salary before on-costs, averaged across the team. Payroll or your talent team can supply the mean.

Employer on-costs and overhead

Payroll tax, superannuation or pension, insurance, tooling and desk cost. Typically 25 to 40 per cent of base.

Time working around existing code

Share of engineering time on rework, defect fixing and workarounds. Take it from ticket categories or a team survey.

Minutes each developer waits on builds daily

Daily time blocked waiting for builds, tests or environments. Your CI dashboard reports pipeline duration and run counts.

Planning horizon

months

The delivery window you are planning, such as a 12 month roadmap or a 6 month programme.

Runs in your browser. Nothing you enter is stored or sent anywhere.

Results

Worked example. Edit the values and press Calculate

Team capacity lost to debt

34.38%

Significant. A large slice of the plan is spoken for before work starts.

Each point of drag removed saves
$15,600.00 a year
One percentage point of team capacity, at the fully loaded cost of the whole team.
Removing build and test waiting saves
$146,250.00 a year
If daily build and test waits fell to zero, with the debt itself unchanged.
Developer-equivalents lost
3.44 developers
You are paying for 10 and planning as if you had 6.56.
Effective team delivering features
6.56 developers
Use this figure, not headcount, when you forecast a roadmap.
Capacity lost to build and test waiting
9.38%
Pipeline time only. This is usually the cheapest part of the drag to fix.
Engineering weeks lost over the horizon
158.1 weeks
Forty hour weeks of delivery capacity consumed rather than shipped.
Hours lost over the horizon
6,325 hours
Based on 1,840 productive hours per developer per year after leave and holidays.
Fully loaded cost per developer-hour
$84.78
Salary plus on-costs divided by productive hours, not by 2,080.
Cost of the drag over the horizon
$536,250.00
Of a total team cost of $1,560,000.00, leaving $1,023,750.00 on features.
Annualised cost of the drag
$536,250.00
The recurring figure. It repeats every year until the underlying problem is fixed.
Break-even remediation budget
$536,250.00
Spend up to this on remediation and you are square within twelve months if the drag is removed.
Velocity impact
Significant
Banding for the total capacity drag, not a judgement on code quality.

Team capacity lost to debt: The share of paid engineering time that never reaches a customer. This is the headline figure to take into a planning conversation.
Each point of drag removed saves: The yearly value of winning back one percentage point of team capacity, at the fully loaded cost of every developer. Multiply it by the points a clean-up project would remove to judge the project.
Removing build and test waiting saves: The yearly capacity cost of developers waiting on builds and tests, which you would recover if pipelines were fast enough to remove the wait. It is usually the cheapest part of the drag to fix.
Developer-equivalents lost: Your capacity drag converted into whole people. It is the most persuasive framing because it contradicts headcount-based forecasts directly.
Effective team delivering features: The team size you should actually plan against. Forecasting on raw headcount is how roadmaps slip without anyone being able to explain why.
Capacity lost to build and test waiting: The portion of drag caused by slow pipelines and environments. It is usually the cheapest and fastest part of the problem to fix.
Engineering weeks lost over the horizon: Forty hour weeks of delivery capacity consumed by the drag across your planning window, rather than shipped as features.
Hours lost over the horizon: The same capacity in hours, based on 1,840 productive hours per developer per year after leave, holidays and sick time.
Fully loaded cost per developer-hour: True hourly cost including on-costs, divided by productive hours rather than the 2,080 figure that includes leave.
Cost of the drag over the horizon: The money value of the lost capacity across your planning window, with the total team cost and feature spend shown for context.
Annualised cost of the drag: The recurring annual figure. Unlike a one-off project cost, this repeats every year until the underlying problem is addressed.
Break-even remediation budget: The most you could spend on fixing the problem and still be square within twelve months if the drag were fully removed.
Velocity impact: A simple band for the total capacity drag, useful as a summary label in a status report. It is not a judgement on code quality.

Why use this calculator

A dollar figure for technical debt is easy to dismiss because nobody wrote a cheque for it, but a capacity figure is very hard to argue with because it directly contradicts the delivery plan. Telling a leadership team that debt costs half a million dollars a year invites a debate about methodology.

Telling them that a ten person team is delivering like a six person team, and that every roadmap built on headcount is therefore wrong, changes the conversation immediately. This calculator produces the capacity number first and the money second, and it separates the two kinds of drag that behave very differently: time spent working around existing code, which needs sustained architectural work, and time blocked waiting on builds and tests, which is usually a tractable infrastructure problem with a short payback. It also gives you a break-even remediation budget, which is the figure to bring to a funding conversation.

How to use it

Enter the number of developers who actually write or review code, excluding managers and product roles who do not ship changes, because including them flatters the capacity figure.
Put in the average base salary before on-costs, which payroll or your talent team can supply as a mean across the team.
Set employer on-costs and overhead as a percentage of base, covering payroll tax, superannuation or pension, insurance, tooling and workspace, which typically lands between 25 and 40 per cent.
For time working around existing code, use your ticket categories if you track maintenance separately from feature work, or run a simple anonymous team survey, since developer estimates of this are more reliable than managers'.
For build waiting, take pipeline duration and daily run counts from your continuous integration dashboard rather than guessing, and count only time where the developer is genuinely blocked.
Finally set the planning horizon to whatever window you are forecasting, such as a twelve month roadmap or a six month programme.

What each result means

Team capacity lost to debt: The share of paid engineering time that never reaches a customer. This is the headline figure to take into a planning conversation.
Each point of drag removed saves: The yearly value of winning back one percentage point of team capacity, at the fully loaded cost of every developer. Multiply it by the points a clean-up project would remove to judge the project.
Removing build and test waiting saves: The yearly capacity cost of developers waiting on builds and tests, which you would recover if pipelines were fast enough to remove the wait. It is usually the cheapest part of the drag to fix.
Developer-equivalents lost: Your capacity drag converted into whole people. It is the most persuasive framing because it contradicts headcount-based forecasts directly.
Effective team delivering features: The team size you should actually plan against. Forecasting on raw headcount is how roadmaps slip without anyone being able to explain why.
Capacity lost to build and test waiting: The portion of drag caused by slow pipelines and environments. It is usually the cheapest and fastest part of the problem to fix.
Engineering weeks lost over the horizon: Forty hour weeks of delivery capacity consumed by the drag across your planning window, rather than shipped as features.
Hours lost over the horizon: The same capacity in hours, based on 1,840 productive hours per developer per year after leave, holidays and sick time.
Fully loaded cost per developer-hour: True hourly cost including on-costs, divided by productive hours rather than the 2,080 figure that includes leave.
Cost of the drag over the horizon: The money value of the lost capacity across your planning window, with the total team cost and feature spend shown for context.
Annualised cost of the drag: The recurring annual figure. Unlike a one-off project cost, this repeats every year until the underlying problem is addressed.
Break-even remediation budget: The most you could spend on fixing the problem and still be square within twelve months if the drag were fully removed.
Velocity impact: A simple band for the total capacity drag, useful as a summary label in a status report. It is not a judgement on code quality.

The formula

Capacity drag = the share of time working around existing code plus build waiting expressed as a share of the day, capped at 95 per cent

Build drag = daily build waiting minutes divided by 480 nominal working minutes

Developer-equivalents lost = team size multiplied by capacity drag

Fully loaded salary = base salary multiplied by one plus the on-cost percentage

Cost per developer-hour = fully loaded salary divided by 1,840 productive hours per year

Hours lost = team size multiplied by 1,840 multiplied by the horizon in years multiplied by the drag

Annual cost = team size multiplied by fully loaded salary multiplied by the drag, and the break-even remediation budget equals that annual cost

How this number is used in practice

Ward Cunningham coined the debt metaphor to describe a deliberate trade: ship now against an imperfect understanding, then repay by refactoring as understanding improves. Martin Fowler later split it into a quadrant of deliberate versus inadvertent and prudent versus reckless, which remains the most useful framing available because it separates debt that was a reasonable decision from debt that was simply never noticed.

That distinction matters when you present this calculation, because the response is different. Prudent deliberate debt needs a repayment schedule and a date. Inadvertent debt needs design review, pairing and better feedback loops so the team stops creating it unknowingly. Reckless debt needs a conversation about standards. Presenting one undifferentiated number invites the answer that all code is imperfect and nothing can be done.

Build and test waiting deserves its own line because it behaves differently from every other kind of drag. It is precisely measurable from continuous integration data rather than estimated, it compounds across the whole team simultaneously, and it has a well-documented effect on how developers work: once feedback takes longer than a few minutes, people context-switch, batch up larger changes, and review less carefully, which then generates more defects.

The DORA research programme has consistently found lead time and deployment frequency to be among the strongest predictors of delivery performance, and pipeline duration sits directly upstream of both. It is also usually the cheapest thing on the list to fix, because caching, parallelisation, test selection and better runners are ordinary engineering work with a measurable before and after.

If you need a first win to establish credibility for a larger remediation programme, this is normally where to start.

The reason to lead with capacity rather than money is that capacity is the currency a delivery plan is actually written in. A finance director can and will argue with a cost-of-debt figure, because the salary was going to be paid either way and no invoice exists.

Nobody can argue that a team of ten which loses a third of its time is planning as though it were a team of ten. Present the developer-equivalents figure next to the roadmap, ask which items come out, and the discussion moves from whether debt matters to what the team is going to stop doing.

The break-even remediation budget then converts that into a funding ask with an explicit payback period, which is the form an investment committee expects. Finally, re-measure. The value of this calculation is not the first number but the trend across quarters, because a drag figure that is falling is evidence a remediation programme is working, and one that is flat tells you the effort is being absorbed rather than compounded.

Worked examples

Ten developers on $120,000 base with 30 per cent on-costs, 25 per cent rework and 45 minutes a day on builds
34.38 per cent capacity lost, 3.44 developer-equivalents gone and $536,250.00 a year
A 25 developer platform group on $150,000 with 40 per cent rework and 90 minutes a day of pipeline waiting, six month horizon
58.75 per cent capacity lost, 14.69 developer-equivalents gone and $2,864,062.50 a year
A healthy eight person team on $130,000 with 10 per cent rework and a ten minute pipeline
12.08 per cent capacity lost, 0.97 of a developer and $157,083.33 a year

When people use it

Funding a refactoring programme or a dedicated platform team with an explicit payback period
Correcting a roadmap forecast that was built on headcount rather than effective capacity
Justifying investment in continuous integration speed, test reliability and developer environments
Comparing the cost of maintaining a legacy system against the cost of replacing it
Tracking whether a remediation programme is working by re-measuring capacity drag each quarter

Tips

Lead with developer-equivalents lost, not dollars. A capacity figure contradicts the delivery plan directly and is far harder to wave away.
Measure build waiting from your continuous integration data rather than estimating it. It is the one input you can get exactly, and it is usually the cheapest to fix.
Survey the team anonymously for the rework percentage. Managers consistently estimate it lower than the people doing the work.
Re-run the calculation every quarter. The trend is the evidence that a remediation programme is working; a single snapshot proves nothing.
Separate deliberate debt with a repayment date from debt nobody noticed. They need completely different responses and mixing them stalls the conversation.
Allocate a standing share of every iteration to remediation rather than asking for a special project. Standing allocations survive priority changes; special projects rarely do.
Attack the debt sitting on the paths you change most often. Debt in code nobody touches costs nothing and fixing it is a vanity project.

What it assumes, and where it stops being accurate

Assumes 1,840 productive hours per developer per year, being 46 weeks at 40 hours after leave, public holidays and sick time. Using 2,080 overstates capacity and understates true hourly cost.
Assumes rework time and build waiting are independent and additive. If your rework estimate already includes waiting on pipelines, you will double count and should enter a lower build figure.
Total drag is capped at 95 per cent, because a team losing all of its capacity would ship nothing and the model stops being meaningful before that point.
Self-reported estimates of time spent on rework are directional. Surveys, ticket categories and commit analysis all produce different answers, typically within a 10 to 15 percentage point band.
Removing debt is treated as removing the drag entirely for the break-even calculation. In reality remediation recovers part of it, so treat the break-even budget as an upper bound.
Not accurate for very small teams where one person's specialised knowledge dominates, or for research and prototyping work where rework is the point rather than a defect.
Contractor rates, recruitment cost, and the opportunity cost of features never attempted because the codebase made them look impossible are all excluded.

Terms used on this page

Technical debt: Design or implementation shortcuts that make future change more expensive, named by analogy with financial debt that accrues interest.
Developer-equivalent: Lost capacity expressed as whole people: a 30 per cent drag on ten developers equals three developer-equivalents.
Fully loaded cost: Salary plus payroll tax, pension or superannuation, insurance, tooling and workspace, which is what a developer actually costs.
Continuous integration: Automatically building and testing every change. Its duration sets how fast a developer learns whether their change works.
Lead time for change: Elapsed time from a commit to that change running in production. One of the core delivery performance measures in the DORA research.

Questions people ask

What actually counts as technical debt?: Anything in the code, architecture or tooling that makes future change more expensive than it needs to be: shortcuts taken under deadline, missing or unreliable tests, outdated dependencies, duplicated logic, undocumented behaviour, and slow build and deployment pipelines. The last of these is often excluded from definitions, yet it is frequently the largest measurable drag on a team.
Why express debt as capacity instead of money?: Because capacity is the currency delivery plans are written in and money is not. A cost figure invites a methodology argument, since the salary was going to be paid anyway. Saying a ten person team is delivering like a six person team directly contradicts every forecast built on headcount, which is a much harder statement to dismiss.
How do I measure the percentage of time lost to rework?: Use ticket categories if you separate maintenance from feature work, run an anonymous team survey, or sample a few weeks of work explicitly. All three give different answers, usually within ten to fifteen percentage points of each other, so take the range rather than a single figure and state which method you used.
Why 1,840 hours a year and not 2,080?: 2,080 is 52 weeks at 40 hours and assumes nobody takes leave, is never sick and never has a public holiday. Using it understates the true cost of an engineering hour and overstates how much capacity a team has. 1,840 allows roughly six weeks a year for leave, holidays and sickness, which is closer to reality in most markets.
Is all technical debt worth repaying?: No. Debt in code that nobody changes costs nothing, so repaying it is effort with no return. Target the debt on the paths your team touches most frequently, which is where the drag actually accrues. A simple way to find it is to overlay change frequency on complexity and work on what scores high in both.
How much time should a team spend on remediation?: A commonly used standing allocation is 15 to 20 per cent of every iteration, treated as non-negotiable rather than the first thing cut when a deadline approaches. A standing allocation survives priority changes far better than a special project, and it stops debt compounding between the occasional large clean-up efforts.

Use this with

Technical Debt Cost Calculator answers one part of the question. These pick up where it stops: Employee Cost Calculator, Hiring Cost Calculator, IT Downtime Cost Calculator, Cloud Cost Comparison Calculator and Freelance Rate Calculator.

Where these figures come from

Works anywhereLast reviewed 2026-09·How we build and check calculators

This calculation is jurisdiction-neutral arithmetic. No country-specific rules are applied.

Martin Fowler on Technical Debt. Origin of the metaphor and the deliberate versus inadvertent quadrant
DORA. Research on delivery performance, lead time and deployment frequency
Google SRE Book. Toil, error budgets and the cost of unautomated operational work
ThoughtWorks Technology Radar. Current practice on codebase health and remediation approaches

Technical Debt Cost Calculator produces an estimate for general information. It is not financial, tax, medical, legal or engineering advice. read the full disclaimer. Spotted a wrong number? Report it and it gets fixed. The form picks up this calculator and the inputs you used.