The technical debt
measurement reference.
A guided calculator that walks you through three measurement frameworks, shows the formula behind every number, and outputs board-ready figures. Where techdebtcalculator.com gives you tools, this site teaches the thinking behind them.
Guided assessment.
Choose a methodology, supply the inputs that match your evidence base, and read the ledger output with formulas attributed.
Financial Impact Model. Best when you need a board-ready dollar figure and lack code-analysis tooling. Inputs are estimates: precision matters less than internal consistency.
Salary plus benefits, payroll tax, equipment, allocated overhead. Roughly 1.3x base.
Stripe found 33% average. McKinsey reports a 20 to 40% range across engineering organisations.
Older codebases compound debt cost. We apply a 3.5% per year multiplier (CAST 2024).
Sev 1 and Sev 2 incidents. Default cost per incident: $14,500 (industry mean, 2024).
| Period | Principal carried | Interest accrued | Total period cost |
|---|---|---|---|
| Year 1 | $688K | $0 | $688K |
| Year 2 | $688K | $124K | $812K |
| Year 3 | $688K | $270K | $959K |
| Cumulative | $2.46M |
Estimates are sensitive to debt-time fraction, the input most likely to be guessed. Run two scenarios: 25% (optimistic) and 40% (realistic for codebases over four years old per Stripe data). The McKinsey 20 to 40% band is the credible bracket to cite.
Methodology comparison.
There is no single correct way to measure technical debt. The right framework depends on your tooling, your audience, and the precision required. Full analysis on the frameworks page.
| Framework | Inputs | Output | Best for | Tooling |
|---|---|---|---|---|
| TDR | Remediation cost, dev cost | Percentage | Code-level measurement | SonarQube, Code Climate |
| SQALE | Issues, remediation time | A to E rating | Industry-standard reporting | SonarQube, plug-in |
| CAST | Violations, principal $ | Dollar principal | Enterprise portfolios | CAST Highlight |
| Financial Impact | Team size, salary, % | Annual dollar cost | Board presentations | None required |
| Time Based | Sprint capacity, debt hours | Capacity loss % | Agile teams | Existing retros |
The reference, mapped.
Frameworks
SQALE, TDR, CAST, Financial Impact, Time Based, side by side.
True Cost
Cost per engineer at $100K, $130K, $160K, $200K. Compounding model.
Assessment
Score eight dimensions with weighted methodology and benchmarks.
Taxonomy
Fowler's quadrant. Eight categories with cost ranges and remediation.
Management
Five strategies compared. Decision tree for your context.
Business Case
Five slide framework for presenting debt to your board.
Enterprise
Portfolio level measurement across dozens or hundreds of systems.
Sprint Budget
Capacity allocation models. The 20% rule and alternatives.
Common questions.
01How do you calculate technical debt?+
Three methodologies dominate. The Technical Debt Ratio (remediation cost divided by development cost) is the SonarSource and CAST default for code-level measurement. The Financial Impact model multiplies team payroll by the fraction of time lost to debt, useful when you have no static-analysis data. The Time-Based approach extracts debt hours from sprint retrospectives. The right choice depends on your tooling, your audience, and the precision you need.
02What is a good technical debt ratio?+
Below 5% is healthy and aligns with SQALE rating A. 5 to 10% is manageable (rating B). 10 to 20% is concerning (rating C) and warrants dedicated debt sprints. Above 20% is critical (rating D) and typically blocks new feature work without intervention. Above 50% (rating E) is severe enough that rebuild is often cheaper than refactor. These thresholds come from SonarSource and CAST published benchmarks.
03How much does technical debt actually cost?+
CISQ estimates the annual US cost of poor software quality at $2.41 trillion. Stripe found developers spend 33% of their time on debt-related work on average. McKinsey reports a 20 to 40% range across engineering organisations. CAST research shows debt grows 15 to 25% per year if unaddressed. For a 12-engineer team at $145K loaded salary with 28% debt time, that is roughly $570K per year in velocity loss alone before incident costs.
04What is velocity tax?+
Velocity tax is the percentage of sprint capacity consumed by debt-related friction rather than feature work. It captures workarounds, debt-forced rework, debugging time on legacy code, and onboarding overhead. A 30% velocity tax means your team ships 70 units of value for every 100 units of effort. The tax compounds because each new feature must navigate around accumulated complexity.
05How accurate are these calculations?+
The Financial Impact model has roughly plus or minus 30% precision because it relies on debt-time estimation. The Technical Debt Ratio is more precise (plus or minus 10%) when you have SonarQube or Code Climate output, but only captures code-level debt. Time-Based estimation is the least precise individual data point but the most defensible because it is grounded in retrospective evidence. Best practice: run two methodologies and compare.
06How much should we budget for debt repayment?+
The 20% rule (reserve 20% of every sprint for debt) is the most common starting point and works well for moderate debt. For TDR above 20%, dedicated debt sprints quarterly are more effective. For severe debt (above 50%), debt ceilings that pause feature work until a threshold is met outperform fixed allocations. See the management strategies page for the decision flowchart.
07Why do you cite Stripe, McKinsey, and CISQ?+
These three sources publish the most rigorous quantitative research on developer productivity and software quality cost. Stripe surveyed 1,000+ developers for the Developer Coefficient study. McKinsey aggregates benchmark data across IT engagements. CISQ (Consortium for Information and Software Quality) publishes the cost of poor software quality report annually. Together they provide the credible bracket within which most organisations fall.