In this article
Technical debt is not always a bad thing
According to our State of Software 2026 report, improving a system’s maintainability can frees up between €120,000 – €870,000 of development capacity per system per year.
Technical debt is the extra effort teams spend maintaining and changing software because of earlier shortcuts or suboptimal choices. According to Deloitte, technical debt accounts for between 21% and 40% of an organization’s IT spending.
Now, before you start planning a huge cleanup, you cannot pay off all your technical debt, nor should you.
Plot twist: Not all technical debt is a problem.
Intentional tech debt is a reasonable business decision: a deliberate shortcut taken to ship faster, with a plan to address it. The costly issue is unintentional debt: debt that has accumulated without anyone noticing, without a plan to address it, and without visibility into where it sits or what it costs.
It’s all about knowing where debt sits in relation to business activity, and investing in the right places at the right time.
Of course, 21% to 40% of IT spending is a lot to spend on fixing old decisions.
Reducing technical debt starts with choosing which debt to fix. Prioritizing it means deciding which debt to fix first, which to schedule, and which to leave alone.
This article is about that.
Why should you prioritize technical debt?
Technical debt is inevitable.
Ger Cloudt, author of What Is Software Quality, couldn’t have said it more clearly on the SIGNAL podcast. Building software with zero debt is impossible.
This year, AI has raised the stakes.
While AI can also help fix code-level debt such as duplication and complexity. Architectural debt needs whole-system context that AI tools typically lack, and it is the type growing fastest.
According to Gartner,
- by 2027 architectural debt will account for 80% of all technical debt.
- by 2028 AI will create more technical debt on architecture levels than it solves.
Code now arrives faster than anyone can review it, so debt grows faster than review capacity. So, how can you know where to start paying off your technical debt?
5 steps to prioritize technical debt
So, how do you prioritize which technical debt to get rid of and which to keep?
Let’s dive in.
Step 1: Make the debt visible
Having a portfolio view before ranking anything is key.
That way, you can record where the debt sits, what type it is (code, architecture, security, open source), how serious it is, and which systems matter most to the business.
Most organizations cannot do this today. They know which systems hurt, but often not why, or how the picture has changed over the past six months.
A team backlog cannot give you this view, because it shows one system at a time.
The technical debt management guide explains the portfolio approach. If you lack a platform, a register with a location, impact, quadrant, estimated interest per sprint, and proposed fix per entry is a workable start.
Include AI in that picture. Without knowing where AI-generated code sits, you cannot prioritize it for review or tell whether risk is growing.
Step 2: Rank by business impact
The highest-priority systems are the ones where three answers overlap: they change frequently, they are business-critical, and they are structurally fragile.
Fixing those first delivers the fastest return.
Within a system, rank the debt by how much rated code it puts in a bad risk bracket. Sigrid’s maintainability ratings are weighted by lines of code, so a hundred medium-severity findings can outweigh a handful of very high ones, and sorting by severity alone can leave a rating where it was. Candidates that appear under several maintainability properties come first, because one fix moves more than one rating.
Stage large modernizations in increments.
The roadmap is the best filter. Ger Cloudt gave an example in the same podcast I mentioned earlier, in the episode he highlights a function with high cyclomatic complexity (many branching paths).
If a planned feature has to change that function, refactor it, because the work pays back when the feature ships. If nothing on the roadmap touches it and it has sat there for years, leave it alone. He recommends reviewing the debt backlog against the product backlog before each release, and he has rarely seen teams do it.
That logic applies to maintainability debt. Security findings and risky open-source libraries are different, because they can be urgent. Triage new findings every sprint and decide whether to fix or accept each one, and update libraries with known vulnerabilities with far higher priority.
Luc Brandts, SIG’s CEO, makes the same point in a recent technical debt management webinar with a party analogy: before guests arrive, you clean the living room. But you can probably leave the attic messy as is.
A stable system with a planned phase-out can carry debt that would be unacceptable in a system under active development.
One caution from the our technical documentation: if nobody has touched a file in years, its debt is probably low priority. First check whether it should have been changed and nobody dared. Developers know where it hurts, and their view is a good input to validate against change data.
AI also changes the weighting.
Code-level debt such as duplication, complexity, and poorly structured functions is increasingly within reach of AI tooling.
However, architectural debt needs context about the whole system that AI tools lack, so it stays expensive, and it is the type growing fastest.
Step 3: Calculate the cost of technical debt
Technical debt competes with features once it has a number. Two figures do the job:
- Interest: the development capacity a system consumes to stay operational, rather than to deliver new functionality, multiplied by the cost of a developer.
- Principal: the effort to remediate. Divide it by the annual capacity recovered to get a payback period.
SIG’s benchmark of more than 40,000 systems and 600 billion lines of code makes the interest concrete. At an average developer cost of €150,000 per year, moving a system from 2 to 4 stars on maintainability frees up about 5.8 FTE, which is about €870,000 per year.
Moving from 3 to 4 stars frees up about 0.8 FTE, or about €120,000. Ten systems at 2 stars carry roughly €9 million per year in avoidable maintenance.
Those savings come from sustained improvement. A handful of refactors on a large system will not move a star rating, but clusters of related fixes will.
This also changes the conversation with non-technical business leaders.
Show where a system stands, what a 30% improvement costs, and what it returns in delivery speed and cost.
Being able to translate technical lingo into business KPIs is super important.
That gives developers a case they can defend and managers a basis for long-term decisions. Labor is only part of it. In the webinar, we described costing the turnover and burnout that technical debt contributes to, using the share of engineers who leave multiplied by the cost of replacing them.
And to add on top of it. Maintenance also carries a token cost now. AI spend is usage-based and behaves more like cloud spend than headcount, so give it a line next to FTE time.
It also answers a common objection: that AI can regenerate a cleaner version of a messy system. Rework with AI costs tokens each time, and past a certain system size, more tokens do not help, because agents work within a limited context window.
The cost of technical debt covers the cost side in more detail.
Step 4: Reduce technical debt as part of normal delivery
Make debt work part of normal delivery.
- Plan it with the roadmap.
Review the debt backlog against the product backlog every release, and put debt and feature work in the same decision process. - Combine it with change.
Clean up maintainability debt in code you are changing anyway. The team benefits right away and avoids context-switching to unrelated areas. - Refactor in small slices.
Fixing small pieces early costs far less than a large rewrite later. - Tighten the definition of done.
Include quality expectations in the definition of done so new work does not add fresh debt. - Agree on the target.
A safety-critical system, a consumer product, and a prototype warrant different quality levels. Set objectives from business metrics, and skip the blanket aim of removing everything. Having everything perfect is gold-plating. - Check continuously. Feedback should reach developers and agents before debt reaches production, and not six months later in an audit. Gate changes in the pipeline and the IDE.
- Give AI coding agents context. Coding assistants lack architectural context, so supply it, for instance through MCP. In SIG’s analysis of three AI-built systems, the one built with a human in the loop scored markedly higher on maintainability and architecture than the two built by agents alone.
- Talk about it as a business issue.
As SIG CTO Jasper Geurts put it in the webinar, technical debt is also a CFO problem. Engineers can raise it, but leadership has to give them room to act.
Step 5: Measure technical debt and track progress
Choose measures that support decisions:
- Change failure rate and incident frequency.
- Maintenance effort and rework.
- Test coverage and open defects.
- Maintainability and architecture ratings over time.
- Security and open-source findings on the systems that matter most.
- AI-generated code, tracked separately. In the State of Software 2026 we show how AI-generated code scored lower on maintainability than human-written code, especially in large systems.
Common mistakes in technical debt management
- Treating all technical debt as equal, which produces a noisy backlog.
- Leaving ownership unclear.
- Assuming AI will clean up the debt on its own.
- Using developer frustration as the only input.
- Ranking by ease of fixing, which lets quick wins crowd out high-risk debt.
- Treating every legacy system as debt.
If you want to avoid mistakes but don’t know how to get started, we can help. Our Technical Debt Scan can quickly show where your debt sits today, so you can start ranking it with real data.
Sigrid® Core can track debt continuously across the portfolio, so priorities stay current as systems and AI-generated code change. Sigrid® Axis holds your AI coding agents to a deterministic, benchmarked standard while they work and can help reduce technical debt.
In May 2026, Software Improvement Group got recognized as a Leader in the 2026 Gartner Magic Quadrant™ for Technical Debt Management Tools.
About the author
Werner Heijstek
Werner Heijstek is the Chief Delivery Officer at Software Improvement Group and host of the SIGNAL podcast, a monthly show where we turn complex IT topics into business clarity.
Frequently asked questions
How do you reduce technical debt?
Prioritize it first. Rank debt by business impact, then fix it in the systems that change often, are business-critical, and are structurally fragile. Combine cleanup with planned feature work, refactor in small slices, and check new code continuously so debt does not return.
What is the first step in prioritizing technical debt?
Build a portfolio view that shows where debt sits, what type it is, how serious it is, and which systems matter most to the business. Without it, ranking tech debt is guesswork. Get started with our Technical Debt Quick Scan.
Should you fix all technical debt?
No. Some debt is a sound trade-off, and zero debt is impractical. Fix debt in systems that change often, are business-critical, and are structurally fragile, and leave stable, rarely changed code alone, unless it carries security vulnerabilities or outdated libraries, which need a faster response.
Is technical debt bad?
Not always. Deliberate debt with a payback plan is a sound trade-off, such as a quick fix that restarts a stalled production line. Debt that builds up unnoticed, with no plan and no visibility into where it sits or what it costs, slows delivery and raises cost and risk.
Does AI reduce technical debt?
AI can help fix code-level debt such as duplication and complexity. Architectural debt needs whole-system context that AI tools lack, and it is the type growing fastest.