After a code audit I had a document full of findings and no plan. Flaky integration tests around the payment path. A circular dependency between two modules that made every change feel risky. A deploy step that lived only in one engineer's memory. A public API with no written contract. All real, all written down, all sitting in a list that nobody could act on, because a list of problems is not a roadmap.
A findings list is not a roadmap
A roadmap is a sequence with a rationale. It says: these three things first, in this order, because they are cheap relative to the risk they remove; these two wait until Q3 because they depend on the first three; this one is documented and explicitly accepted. That is a different artefact from an audit, and building it by hand from raw notes is where I kept stalling.
The other thing an audit never gives you is a shared vocabulary. "Tech debt" gets used for four unrelated problems, and treating them as one backlog is why the prioritization conversation goes in circles. A flaky test and an undocumented deploy runbook are not the same kind of debt, they do not have the same fix cost, and they do not worry the same people.
Tech Debt Audit & Governance Roadmap takes the findings you already have and returns a prioritized roadmap across code, architecture, test, and documentation debt, with effort, benefit, and risk on each item, plus a quarterly governance plan and a radar chart of current versus target. It also ships a ready-to-run Cursor audit prompt. That last piece matters more than it sounds: the prompt is how you produce the findings in the first place, so the tool covers the loop from "I should look at this repo" to "here is the quarter".
Four axes, because the word "debt" hides four problems
Splitting the backlog into code, architecture, test, and documentation changed my planning immediately. Code debt is local and usually cheap: a confusing function, a duplicated branch, a magic number. Architecture debt is structural and expensive: the circular dependency, the module boundary that every feature has to route around. Test debt is a confidence problem: I cannot refactor safely because I do not know what will break. Documentation debt is a bus-factor problem: the deploy step that only one person knows.
Those four have different effort curves and different payoffs, so scoring them on separate axes is more useful than a single "debt score". The radar of current versus target gives me a picture I can put in front of a non-engineer without a spreadsheet, and the quarterly roadmap turns that picture into a sequence with owners and a time horizon. I am careful with the word "target": it is a planning goal I set, not a benchmark the tool measured.
The radar and the prompt are inputs, not measurements
Here is the honest limit, and it is the one most likely to be misread. The tool does not scan your repository. It works on the code-audit findings you paste into it. The scores, the radar, and the roadmap are a structured view of those inputs, not an independent measurement of your codebase. If the findings are thin, the plan is thin. Garbage in, plan-shaped garbage out.
The Cursor audit prompt is included so you can go produce better findings yourself; the tool does not execute it, does not open your editor, and does not read your repo. And the roadmap is decision-support for a planning conversation, not a measured audit, a certification, or a live audit of your systems. It will not tell you a service is about to fail, and it should not be used as evidence that one is healthy. I still take the output to the engineers who own the code and let them correct the effort estimates, because they know things a pasted list cannot.
If your audit findings are still a document nobody has turned into a plan, pasting them into Tech Debt Audit & Governance Roadmap will at least give you a first draft with the four axes separated and a quarter attached. Then do the part the tool cannot: argue about the order with the people who will do the work.
FAQ
Does it scan my repo or run the audit for me?
No. It works on the code-audit findings you paste. The included Cursor audit prompt is yours to run; the tool does not execute it or read your codebase.
Is the radar a measurement of my architecture?
No. It is a visualization of the scores from the findings you supplied, with a target you set. It is decision-support, not a measured audit or a certification.
What does the quarterly roadmap actually give me?
A prioritized sequence across code, architecture, test, and documentation debt, with effort, benefit, and risk on each item. The final call on order still belongs to your team.
Top comments (0)