How Much Technical Debt Is Acceptable? Thresholds That Work
Zero debt means zero shipping. Here's how to tell cheap leverage from expensive drag — with numbers.
Good debt vs bad debt
Debt is acceptable when it is young, owned, and cheap. You took a shortcut to ship revenue early, you wrote down what it costs, someone owns it, and it gets paid back on schedule. That's leverage — the original metaphor behind technical debt.
Debt is unacceptable when it is old, orphaned, and expensive: 200-day-old items nobody owns, accruing carrying cost every day, causing the incidents you then call "bugs." Same word, opposite economics.
Three thresholds that work
Forget a single "debt ratio." Watch three signals together:
| Signal | Green | Yellow | Red: act now |
|---|---|---|---|
| Age (share >180 days) | <20% | 20–30% | >30% |
| Overdue (past target date) | <10% | 10–15% | >15% |
| Burn ($/day vs capacity) | Burn <10% of sprint value | 10–20% | >20% or rising 3 months |
Example: 25 items averaging 8h at $75/h = ~$15,000 principal, ~$4.93/day at 12% APR (~$1,800/yr). If your team ships ~$5,000 of value per day, that burn is under 1% — green. If the same backlog sits untouched for a year while incidents pile up, age trips red even though dollars look small. Dollars and age together catch what either alone misses.
Find your burn in 30 seconds — then compare it to sprint capacity.
Try the debt calculatorWhen to stop features and pay down
Stop features for a timeboxed payoff sprint when any red trips — or when incidents trace back to known debt. Don't declare "debt quarter." Run a 30-day payoff slice: take the top items by daily burn and 0–100 score that fit real weekly capacity, fix them, and re-measure. "This month saved ~$540/yr" earns the next slice; "the code is messy" doesn't.
Also watch velocity: resolved vs added hours over 90 days. Above 1.0 you're paying down, 0.7–1.0 you're holding, below 0.7 debt is growing. A growing backlog with red age means the next feature costs more than its estimate — say so with numbers.
How to stay green without slowing down
- Budget 15–20% capacity for payoff every sprint. Green teams don't have less debt — they pay interest on schedule.
- Price at capture. Every debt item gets optimistic/likely/pessimistic hours plus rate and APR on day one. Unpriced debt becomes red debt.
- Expire old items. Anything untouched for 180 days gets re-scored, re-owned, or closed. Stale "someday" tickets are how green turns red quietly.
RefactorIQ tracks all three thresholds by default: age distribution, overdue view, and portfolio burn — plus Value Delivered so you can prove the payoff worked.
See your age, overdue, and burn in one place. Free Demo, no account.
Download RefactorIQFAQ
How much technical debt is acceptable?
Debt is acceptable while it is young, owned, and cheap: under ~20% of items over 180 days old, under 10% overdue, and daily burn below ~10% of sprint capacity value. Above that, stop features and pay down.
What is a good technical debt ratio?
Track resolved vs added hours over 90 days. Above 1.0 you are paying down; 0.7–1.0 is holding; below 0.7 debt is growing. Pair it with age and burn — ratios alone hide old, expensive items.
When should we stop features to fix debt?
When any red threshold trips: >30% of items older than 180 days, >15% overdue, critical/high share climbing, or incidents traceable to known debt. Timebox the payoff to 30 days, then re-measure.
Is zero technical debt realistic?
No — and pursuing it wastes money. Debt is leverage when it ships revenue early and gets paid back on schedule. The goal is visible, priced, scheduled debt, not zero debt.
Who should own the debt thresholds?
The tech lead owns the numbers, the team owns the input. Engineers score severity and risk, product weighs business impact, and the lead publishes the green/yellow/red snapshot every sprint review. Shared ownership keeps thresholds honest: when the people feeling the pain set the dials, red actually means stop.