Tech debt prioritization calculator
List your debt items and score each one. You get a ranked paydown plan, an estimate of what carrying the debt costs each year, and a one-liner for the board. No signup, nothing stored.
By the CTO Coach Team · Last updated 2026-10-11 · How this is calculated
Part 1: what debt costs your team
Whole number.
Your own assumption (salary, benefits, overhead), not a benchmark. Default is a placeholder.
Your estimate, 0 to 60. For reference only: a 2018 Stripe survey found developers spend about 17.3 hours a week on maintenance such as debugging and refactoring (source). It is one old survey, not a default truth.
Part 2: your debt items (up to 10)
Rows without a name are ignored. Impact: revenue, customer or velocity. Risk: security, outage or compliance. Effort: 1 is days, 5 is quarters.
Estimated annual cost of carrying debt
$375,000
Formula: engineers x cost per engineer x share of time = 10 x $150,000 x 25%. This is an estimate built from your own assumptions.
Name at least one debt item in Part 2 to see the ranking, the allocation band and the board one-liner.
How this is calculated
These are the exact formulas the tool uses. Nothing else is hidden.
- Annual cost of carrying debt
engineers x fully loaded annual cost per engineer x (% of time lost / 100)
- Item score
score = (impact + risk) x (6 - effort) if the debt is getting worse each month: score = score x 1.25
- Quadrant label
Quick win score >= 30and effort <= 2 Strategic project score >= 30and effort >= 3 Opportunistic score < 30and effort <= 2 Park everything else
- Suggested allocation
high-risk share = items with risk >= 4/ all named items under 25% -> 15-20% of capacity 25% to under 50% -> 20-25% 50% or more -> 25%
Ties in score rank the lower-effort item first, then the order you entered them.
How the score works, and its limits
The score rewards items that matter a lot (impact plus risk) and are cheap to fix. It is a way to start a conversation and break ties, not an oracle. Scores of 1 to 5 are judgments, so two people will score the same item differently. Score together with your leads, and treat a gap of a few points as a tie. The 30-point threshold and the 1.25 multiplier are our rules of thumb, not research findings.
Cost of debt: why the number is an estimate
The dollar figure multiplies three things you supply. The cost per engineer is your assumption. The time share is your estimate of what leaves the team each year to workarounds, slow builds and fixing the same things twice. Surveys give context but not a default: for example, 62.4% of professional developers in Stack Overflow's 2024 survey named technical debt their top frustration at work, and a 2018 Stripe survey found about 17.3 hours a week spent on maintenance. Use the tool to compare scenarios and to size the conversation, then replace the estimate with your own data as you collect it.
From score to roadmap
Schedule quick wins in the next sprint or two, because they pay back fast. Break strategic projects into slices that each ship value, and put them on the quarterly plan with an owner. Fit opportunistic items into work that already touches the same code. Revisit parked items when their impact, risk or effort changes. For a worked example of living with a debt crisis, read your first tech debt crisis.
Presenting debt to the board
Boards respond to capacity and risk, not code quality. Use the one-liner as an opening line, show the top three items with their risk in plain words, and say what you are asking for. More on the format in board-ready CTO communication. Sizing your first 90 days? Try the 30-60-90 day plan generator.
Frequently asked questions
How much time should go to tech debt?
A sustained 15-25% of engineering capacity is a reasonable range for most teams, with the upper end when many items carry high risk. It is a rule of thumb from our guidance for first-time CTOs, not a measured benchmark. Start where you can protect the time every sprint rather than at a number you will raid in the first crunch.
How do I measure tech debt?
You cannot measure it as one number. Measure its effects instead: time lost to maintenance, change lead time, incident count and developer-reported friction. This calculator ranks debt items by impact, risk and effort and estimates the capacity cost from your own assumptions. Both outputs are estimates, and the page says so.
Is a rewrite ever right?
Sometimes, when the system blocks the business and cannot be improved in slices. Rewrites score high on effort (4 or 5) in this calculator, so they land in Strategic project or Park unless impact and risk are severe. Test whether an incremental path exists before you commit a quarter or more to a rewrite.
How do I explain tech debt to non-technical executives?
Translate it into capacity and risk: how much engineering time it consumes each year, and which items could cause an outage, a security incident or a missed commitment. The board one-liner this tool generates follows that shape, and you should edit it with your own numbers before you use it.
Sources
- Stack Overflow Developer Survey 2024, professional developers Stack Overflow, 2024
- The Developer Coefficient Stripe, 2018
How we source and check figures: Methodology.