Technical Debt Calculator
Updated 27 March 2026
Find out what your technical debt is actually costing. Input your team metrics to calculate annual cost, monthly burn, velocity impact, and 5-year projection.
Your Engineering Team
Annual Cost Breakdown
Calculations use industry-standard benchmarks. Actual costs vary by team, codebase, and context.
The Technical Debt Quadrant
Martin Fowler's debt quadrant categorises debt by two dimensions: whether it was deliberate or inadvertent, and whether it was reckless or prudent.
Knowingly taking on debt without a plan to repay it. Highest long-term cost.
Conscious debt taken with full awareness and a repayment plan.
Debt accumulated through lack of knowledge or skill. Often the most prevalent.
Debt discovered after the fact when better practices are learned.
Explore Technical Debt
How technical debt compounds over time and why deferred paydown gets exponentially more expensive.
The debt sprint approach, the strangler fig pattern, and how to build a business case for paydown investment.
The four quadrants of technical debt and how each one accumulates, compounds, and should be addressed.
Frequently Asked Questions
What counts as technical debt?
Technical debt is the accumulated cost of shortcuts, quick fixes, and deferred improvements in your codebase. It includes: code that is difficult to understand or modify, missing tests, outdated dependencies with known vulnerabilities, architectural decisions that made sense then but limit you now, and documentation gaps that slow onboarding and debugging. The defining characteristic is that it makes future changes more expensive than they would be in a clean system.
How do I estimate my debt percentage?
Debt percentage is the proportion of your engineering team's time consumed by debt-related activities: fixing bugs caused by fragile code, navigating complex legacy systems, working around architectural limitations, handling dependency conflicts, and dealing with flaky tests. Survey your team: ask engineers how many hours per week they spend on debt vs new features. Be honest. Most teams underestimate by 30-50%.
What is a realistic test coverage target?
Industry benchmarks suggest 70-80% line coverage as a healthy minimum for production applications. Below 60% coverage, defect escape rates increase substantially. Note that coverage percentage alone is a poor metric, it matters whether the right code is covered. Critical business logic and integration points should be tested regardless of aggregate coverage numbers.
How is the 5-year compound cost calculated?
The calculator models technical debt as a compound interest problem. Unaddressed debt grows because each addition to a complex codebase adds more complexity than it would in a clean system. The compound rate is modelled at 15-25% per year, with higher rates for codebases with more outdated dependencies (which generate security incidents and forced migration work). This aligns with CAST Software research on software quality economics.
What does velocity impact mean?
Velocity impact is the percentage of your team's productive capacity consumed by debt. A team with 25% debt impact delivers roughly 75% of the feature throughput they would achieve with no debt. This has compounding effects: slower velocity means competitors ship faster, engineers burn out dealing with fragile code, and the debt backlog grows as the system becomes harder to change.
What is dependency freshness and why does it matter?
Dependency freshness measures how current your third-party libraries and frameworks are. A score of 100 means all dependencies are on current major versions. A score of 30 means most dependencies are multiple major versions behind. Low freshness correlates with: known security vulnerabilities, incompatibilities with new tooling, difficult future upgrades, and higher maintenance burden. Outdated dependencies are also a primary driver of debt compound growth because deferred upgrades become progressively more expensive.