Occam - Technical Debt Prioritisation Tool
Paste the tech debt your team keeps talking about, say what the roadmap looks like, and get each item sorted into fix now, schedule, fix when touched or leave it.
Named after William of Ockham, whose razor says not to add anything you do not need. A tech debt list needs the same knife.
To prioritise technical debt, judge each item by the interest it charges rather than how bad the code looks: the time it costs every time someone works near it, the incidents and security risk it carries, and the roadmap work it blocks. Then put every item into one of four buckets: fix now, schedule it, fix it when you are in that code anyway, or leave it and say what would change your mind. Debt sitting in the path of next quarter's roadmap goes first, because that is when paying it down is cheapest. Most debt belongs in the last two buckets, and that is fine. The tool below turns your own list into a tech debt prioritisation matrix: impact, risk and effort for each item, then one of those four buckets and the reason for it.
When a free tool is not enough
A prioritised list is the easy half.
The hard half is holding the line on it for six months while the roadmap keeps shouting. Our fractional CTOs go into the codebase, check whether the debt is what the team thinks it is, and run the paydown alongside feature work so neither one stalls. If you are heading into a raise or a sale, we also run independent technical due diligence, so you see what an assessor will find before they do.
How to use Occam, the Technical Debt Prioritisation Tool
List the debt you know about
One item per line works best. Write it the way your team talks about it: "still on Node 16", "no tests on checkout", "the reporting job times out on Mondays". Up to 4,500 characters.
Describe your team and what is next
Team size, stage and the next quarter of roadmap. This is what turns a generic list into a prioritised one, because debt in the path of the roadmap moves up.
Pick what matters most right now
Shipping faster, fewer incidents, security, an upcoming due diligence or handling growth. The same item can be urgent under one goal and safe to leave under another.
Answer the open questions
If the tool had to guess, the Overview tab says so and the Open questions tab lists what it could not tell from your description. Answer those and rerun if they would change a decision.
Take the plan to planning
Each item comes with a decision, the reasoning, what it costs you and a first step someone can start this week. Download it as a PDF or Markdown and use the stakeholder paragraph when you need the time signed off.
How to prioritise technical debt
Ward Cunningham coined the debt metaphor in his 1992 OOPSLA experience report on the WyCash portfolio system, and the useful half of it is the interest. Shipping code you know is not quite right is borrowing. Every change you make on top of it afterwards pays interest. Some debt charges a fortune every week. Some charges nothing at all, because nobody ever touches that part of the system.
So the first question for any item is "what does this cost us, and how often?". A 3,000-line file that nobody has opened since 2021 is ugly and cheap. A slightly awkward module that four people change every sprint is expensive.
I score every item on three things, then make a decision rather than a ranking:
- Impact. How much time, speed or morale it costs you right now. Slow builds, flaky tests, code everybody is scared to change, workarounds that keep coming back.
- Risk. The likelihood and blast radius of it going wrong: an outage, a breach, lost data, a failed due diligence. An unsupported runtime with known vulnerabilities is high risk even if it costs nothing day to day.
- Effort. A rough size: small, medium, large, or honestly unknown. Not hours. Estimating debt paydown in hours from a description is fiction, and everyone in the room knows it.
- Then the decision. Fix now, schedule it, fix it when you touch it, or leave it. Four buckets a team can act on in the next planning meeting beat a spreadsheet of weighted scores nobody believes.
A tech debt prioritisation framework in four decisions
The tool above sorts everything into these four. They are the same four I use with teams, and the discipline is in keeping the first bucket small.
- Fix now. Real risk of harm, or it blocks the next piece of roadmap work. Security exposure, data loss, recurring incidents, the module the next big feature has to go through. If more than two or three things land here, something has gone wrong with the scoring.
- Schedule it. Worth paying down deliberately as planned work, with an owner and a sprint, in the next month or two. Usually debt with steady interest that will not fix itself.
- Fix when you touch it. Improve it as part of normal work whenever someone is changing that code anyway. Add the tests, rename the thing, pull out the function. Engineers know this as the boy scout rule (leave the code a little better than you found it), and Martin Fowler calls it opportunistic refactoring. This is where most healthy debt paydown actually happens, and it never needs a ticket of its own.
- Leave it. Accept it, write down what would change the verdict (traffic doubles, a customer asks for SOC 2, you hire a second team), and stop talking about it in retros. A written-down decision to carry some debt is a perfectly good outcome.
Technical debt vs new features: who wins?
Neither, if you do it properly. The mistake I see most is treating debt as a separate project that has to compete with features for a slot on the roadmap. It always loses that fight, because a feature has a customer attached and a refactor has an engineer attached.
The better move is to tie debt to the roadmap. If next quarter is SSO and the auth code is a mess, cleaning up auth is part of shipping SSO, and it goes in the estimate. Paying down debt in the code you are about to change is the cheapest it will ever be. Paying it down in code nobody is touching is the most expensive, for the least return.
For whatever is left over, protect a fixed slice of capacity rather than negotiating every item. Teams disagree on the right size of that slice, and it should move with how much the debt is actually costing you. What matters is that it is agreed once and defended, instead of relitigated every sprint.
And when you do need to ask a non-technical founder or board for the time, talk about delivery speed, incidents and risk. A board will not follow an argument about cyclomatic complexity. They will follow the fact that the last three features each slipped by two weeks for the same reason. The tool writes you that paragraph.
Not all technical debt is the same
Martin Fowler's technical debt quadrant, from 2009, splits debt by whether it was deliberate or inadvertent and whether it was prudent or reckless. Shipping something you know will not scale, with a plan to fix it after launch, is deliberate and prudent. A team that never learnt to write tests is inadvertent and reckless. It is a useful lens for retros, because the fix for reckless debt is usually in how the team works rather than in the code.
For prioritisation, the kind matters less than where it lives. The categories the tool uses are the ones that change the decision:
- Dependencies and runtimes. Out-of-support versions are the one category that gets worse on its own, without anyone touching anything. They also go straight to the top of any due diligence report.
- Testing. Missing tests on the flows that make you money turn every change into a gamble, and they are the reason "small" changes take a week.
- Security. Secrets in the repo, hand-rolled auth, missing access controls. If personal data is involved, UK GDPR Article 32 requires appropriate technical measures to keep it secure, so this stops being optional.
- Architecture. The expensive one. Usually "fix when touched" or "schedule", almost never a rewrite. Rewrites are how a one-quarter problem becomes a two-year problem.
- Infrastructure and process. No staging, manual deploys, one person who knows how production works. Cheap to fix, and it pays back on every release after.
- Not technical debt at all. A missing feature, a people problem or a product disagreement written up as tech debt. The tool will say so when it sees one.
What this tool cannot tell you
It works from what you type, not from your code. It has no idea whether the "unmaintainable billing module" is genuinely dangerous or just unfamiliar to the person describing it. Teams regularly misjudge their own debt in both directions: something everyone complains about turns out to be fine, and something nobody mentions turns out to be the real problem. A description cannot surface that. Reading the codebase can.
Effort is a size, not an estimate, and it will say "unknown" when your description does not give it enough to go on. It will never give you hours, days, story points or a cost, because any number produced from three lines of text would be made up.
It is also a language model, so read the decisions as a well-argued starting point for your planning meeting and not as a verdict. The Open questions tab lists the places it had to guess, and the Overview tab flags them when there are any. Answer those first.
Before your first result we ask for your name, work email and company. What you put into that first run travels with those details to our CRM, inbox and team chat, so a person can read it and reply. After that, what you paste goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Either way, leave out secrets, keys, credentials and client names. Describe the problem, not the password.
Frequently asked questions
Rate each item on impact (what it costs you now), risk (the chance and size of it going wrong) and rough effort, then weigh it against what your roadmap needs next. Put each item in one of four buckets: fix now, schedule it, fix when you touch it, or leave it. Anything in the path of next quarter's roadmap goes first. Keep the "fix now" bucket to two or three items.
There is no single number that holds up, so measure what the debt costs you. Tools such as SonarQube estimate code-level debt as time to fix. That works as a trend line, but it cannot see your roadmap or what an item costs the business. The measures that change decisions are per area of the codebase: how long changes there take, how often they break, the incidents traced back to it and the roadmap work it blocks. This tool gives no numeric score or cost figure, on purpose. It rates each item low, medium or high for impact and risk, sizes the effort, then gives it a decision.
There is no universal number, and I would be suspicious of anyone who gives you one without seeing your system. Fold as much paydown as you can into feature work in the same code, then protect a fixed, agreed slice of capacity for the rest, sized to what the debt is actually costing you. Agree it once and defend it, rather than negotiating it every sprint.
Tie the two together. Debt in the code your next feature has to change is part of building that feature, so estimate and ship them together. Debt in code nobody is touching can usually wait. The worst option is a standalone "tech debt quarter", which pauses delivery and rarely finishes what it started.
When you are about to change it anyway. Refactoring the code a feature has to go through, while you build that feature, costs the least, because you already understand that code and it gets tested with the change. That is the boy scout rule in practice. Make it planned work when one area slows every change or keeps causing incidents. Leave code nobody touches alone, however ugly it is, and keep a full rewrite as the last resort, because it pauses delivery for far longer than anyone plans.
A list of known debt items, each with an owner, a rough size, what it costs you and a decision. The download from this tool is a reasonable first version of one. The useful habit is revisiting it when the roadmap changes, because that is when priorities move.
In their terms: how much slower features ship, how often things break, and what it would do to a fundraise or a sale. Name one or two items and what fixing them buys you. Skip the code quality vocabulary entirely. The result from this tool includes a paragraph written for exactly that conversation.
Yes. You get three runs. Before the first result we ask for your name, work email and company, and for you to accept the terms, and that is the whole price. There is no paid tier.
No. It prioritises debt you describe. For measuring debt in the code itself, static analysis tools such as SonarQube report things like code smells and duplication. For a human judgement of what actually matters in your codebase, that is what a code review or technical due diligence is for.
Related from Metamindz
- Fractional CTOA senior CTO on a retainer who reads the code, owns the trade-off between debt and roadmap, and makes the case upstairs.
- Technical due diligenceAn independent assessment of your codebase and team, before a raise, a sale or a big customer review finds the problems for you.
- Vibe-code fixesFor codebases built fast with AI and not much review, where the debt arrived all at once.
- Technical debt vs feature developmentThe longer read on balancing paydown against the roadmap.
- Tools for tracking technical debtWhat to use once you know what you are tracking.
- All free tools
Also known as: Tech Debt Prioritisation Matrix, Tech Debt Prioritisation Framework, Technical Debt Matrix.
Published