What is technical debt really costing you?
Estimate the annual cost of technical debt from signals your team already knows: unplanned work, release speed, incidents, onboarding and test coverage. It also models how much unreviewed AI-generated code adds, and how AI-native refactoring changes the payback on fixing it.
Measure your technical debt
Start from a preset closest to your team, then adjust. The cost and payback update as you go.
- Unplanned work and workarounds$300,000
- Slow delivery pipeline$47,000
- Regression rework$35,000
- Slow onboarding$27,000
- Ageing dependencies and upkeep$25,000
- Unreviewed AI code rework$24,000
- Incident response$19,000
- Traditional (28 months)$76,000
- AI-assisted (24 months)$85,000
- AI-native refactoring (21 months)$100,000
- Debt is a significant but manageable drag. A standing allocation of 15 to 20% of each sprint to remediation usually keeps it from growing.
- If nothing changes, this cost grows to about $560,000 next year and $1.7M over three years.
- 1. Unplanned work is costing about $300,000 a year above a healthy baseline. Tag every bug and workaround by module for a month; a small number of modules often account for most of it, and those are where refactoring pays first.
- 2. Your release process costs about $47,000 a year in waiting and batching. Automate the path to production (CI on every merge, one-step deploys, feature flags) so small changes ship daily.
- 3. Regressions cost about $35,000 a year. Add tests around the code that changes most often before refactoring it, rather than chasing a coverage percentage.
- 4. New engineers take 4 weeks longer than they should to become productive. Document local setup, architecture decisions and ownership, and make the first commit possible on day one.
- With the same budget, AI-native refactoring pays back in about 21 months, against 28 months for a traditional approach, under these assumptions.
- Coding agents are strongest at mechanical work: dependency upgrades, test generation, migrations and dead code removal. Architecture changes still need senior judgement.
- With thin test coverage, any refactoring is risky, AI-assisted or not. Use AI to generate characterisation tests around critical flows first, then refactor behind them.
After remediation, the velocity index would rise to about 77. Assumes 12% unplanned work is normal and that remediation removes at most 60% of the drag.
Indicative only. We will send the inputs above with your message so a senior engineer can sanity-check them.
Measuring technical debt through its symptoms
Technical debt has no line on a balance sheet, so the calculator measures what it does to your team instead. It starts from engineering payroll and asks where capacity leaks away: time on bugs and workarounds above a healthy baseline, waiting and batching caused by slow releases, regression rework, dependency upkeep, incident response and new engineers who take months to become productive.
Each leak is converted into money using your loaded cost per engineer. The result is capped so that no team is shown losing more than three quarters of its capacity, because at that point it would not be shipping at all. The velocity index is simply the share of capacity left for planned work, where 100 means a team spending nothing beyond normal levels on debt.
Test coverage, codebase age and the share of unreviewed AI-generated code do not only add cost today. They set how fast the cost grows if nothing changes, which is why the result shows next year alongside this year.
The remediation model assumes diminishing returns. The first money spent on the worst modules recovers the most, and no programme removes more than about 60% of the drag. AI-native refactoring stretches the same budget further, while thin test coverage makes every approach less effective, because unsafe changes have to be made slowly.
Technical debt metrics: healthy, strained or critical
Indicative bands for a product engineering team. Use them to sense-check your inputs, not as a grading scheme.
| Healthy | Strained | Critical | |
|---|---|---|---|
| Unplanned work | 10 to 15% of time | 20 to 35% | Over 40% |
| Deploy frequency | Daily or on demand | Weekly | Monthly or less |
| Commit to production | Under a day | Several days | Weeks or more |
| Onboarding to productive | 2 to 4 weeks | 6 to 10 weeks | Three months or more |
| Test coverage of core flows | Automated in CI | Patchy, some manual | Mostly manual |
| AI-generated code | Reviewed like any change | Reviewed when someone has time | Merged unread |
Bands reflect commonly reported delivery and quality signals. Context matters: a regulated system may deploy less often by design.
Where the cost of technical debt usually hides
The expensive part of debt is rarely the code itself. It is the time and confidence it takes away from everyone who works near it.
Workarounds that became process
Manual data fixes, restart scripts and "do not touch" modules quietly absorb hours every week, and nobody logs them as debt.
Slow paths to production
When releases are big and infrequent, engineers batch changes, rebase constantly and wait on manual testing instead of building.
Incidents and their aftermath
Every outage pulls several people off planned work, then triggers hotfixes, customer communication and more caution on the next release.
Knowledge locked in a few heads
Undocumented systems slow onboarding and make a handful of senior engineers a bottleneck for every change.
Unreviewed AI-generated code
AI tools write plausible code quickly. Merged without review or tests, it duplicates logic, adds inconsistent patterns and hides security gaps.
Ageing dependencies
Frameworks and libraries that fall several versions behind turn routine upgrades into risky migration projects.
A practical way to reduce technical debt
Debt is never cleared in one go. Teams that make progress treat it as a standing budget with clear priorities.
Measure before you refactor
Tag unplanned work by module for a few weeks. The data usually shows a small number of areas generating most of the pain.
Protect the code that changes most
Add characterisation tests around high-churn modules first. AI tools are good at generating these, as long as an engineer checks they test real behaviour.
Use coding agents for mechanical work
Dependency upgrades, framework migrations, dead code removal and repetitive refactors suit AI-native workflows well. Keep architecture decisions with senior engineers.
Fix the path to production
Automated builds, tests and one-step deploys make small, frequent releases the default and stop new debt from piling up behind a release window.
Make it a standing allocation
A fixed share of every sprint, often 15 to 20%, keeps debt from growing back once the worst of it is gone.
Questions we often hear
How do you calculate the cost of technical debt?
The most practical method is to estimate the engineering capacity it consumes and multiply by the loaded cost of your engineers. That includes excess unplanned work, release friction, rework, incident response and slow onboarding. The result is an estimate, but it is far more useful in a budget discussion than a vague sense that the code is messy.
What is a normal amount of time to spend on bugs and unplanned work?
Healthy product teams commonly spend around 10 to 15% of their time on bugs, support and unplanned work. Once that climbs past a quarter of the team’s time, debt is usually a real drag on delivery. Above 40%, most teams struggle to ship meaningful new features at all.
Does AI-generated code create technical debt?
It can, when it is merged without review. AI tools produce working code quickly, but they also duplicate logic, ignore existing patterns and sometimes introduce security flaws. Reviewed properly, with tests, AI-assisted code need not carry more debt than human-written code, and AI tools can help pay existing debt down.
Can AI help reduce technical debt?
Yes, particularly for mechanical work such as dependency upgrades, test generation, documentation and large repetitive refactors. AI-native teams typically complete that kind of work with fewer engineer-hours. Deciding what the architecture should become, and checking that behaviour has not changed, still needs experienced engineers.
Should we rewrite our system instead of refactoring it?
Rarely as a first choice. Full rewrites commonly take longer than planned and recreate old bugs while the business waits. Incremental refactoring behind tests, replacing the worst parts one at a time, is usually safer. A rewrite becomes reasonable when the platform itself is unsupported or cannot meet a hard requirement.
How accurate is this technical debt calculator?
It is indicative. The multipliers are conservative assumptions, and the quality of the result depends on how honestly the inputs reflect your team. Use it to size the problem and frame a conversation, then validate with a code audit or a few weeks of tracked data.
Related reading and tools
Know which debt to pay down first.
Send us your result and a little context about the codebase. A senior engineer will tell you where the drag most likely comes from, what an AI-native remediation plan could look like, and whether it is worth doing at all.
Working with companies globally · Response within 24 hours