Technical Debt Assessment
Technical debt assessment: which debt is slowing you down, and which you can leave alone
Together with you, we read your code and look at how your team works, then hand you a prioritised debt map and a 90- and 180-day plan.
About 4 weeks, with the first map of critical areas by week two or three
Every codebase carries debt: the problem is not knowing which part of it costs you
A technical debt assessment is a roughly four-week analysis of your code and the way your team works, ending with a map of critical areas ordered by business impact and a 90- and 180-day plan. It matters because technical debt isn't just messy code waiting to be tidied up: it's friction, and it makes the very changes that create value slower and riskier. Until you can see where it's concentrated, every conversation about what to fix stays vague.
Debt always slips down the list, because nobody can say what it actually costs
Discussions about what to refactor end up as a clash of opinions
You have a static analysis report with hundreds of findings and no order to them
Management asks how much the debt is holding back the roadmap, and the answer is a guess
People talk about rewriting everything, without knowing what would be lost
A new CTO has come in and needs to understand the state of the system before deciding anything
The real issue is that nobody has looked at the system as a whole yet
What we analyse, in the code and in the way you work
The assessment looks at technical debt in your actual code, together with the people who change it every day. It isn't an audit handed off to a tool. Analysis tools help us find the areas worth a closer look; the conclusions come from reading those areas together with your team.
Change history and hotspots
From version control we work out which parts of the code change most often and which are the most complex: wherever the two overlap, you pay for the debt with every change.
Coupling and module boundaries
We count how many modules a typical feature has to touch: when it's too many, there's usually an unclear boundary multiplying both the work and the chances of regression.
Testability and test coverage
We don't stop at the coverage percentage: we look at what the existing tests actually describe, and where the code gets changed today with no safety net at all.
Pipeline and release flow
We follow a change all the way to release and see where it gets stuck, whether on a slow build or a manual check.
Dependencies and libraries
Versions stuck in place, unmaintained libraries, updates put off because nobody knows what would break.
Interviews with the team and product leadership
We talk to developers and product leads to understand which features are stuck and where the work meets the most friction.
How it works
There are five phases, and the first map of critical areas arrives before the final presentation: that way we can discuss it with you while there is still time to dig deeper.
- 01
Access and preparation
We agree the scope, get access to what we need and set up interviews with the right people.
- 02
Repository analysis and interviews
We analyse the change history, the structure of the code and the tests; at the same time, we talk to the team and the product owners to understand where work slows down.
- 03
Expert analysis
We read the critical areas together with the developers and check the data against what actually happens. This is where the first map takes shape.
- 04
Map and plan
We assign an action to every area and build the 90- and 180-day plan, ordered by business impact.
- 05
Final presentation
We present the map, the plan and an executive summary to the CTO and management, and answer the decision-makers' questions.
Two formats, chosen to fit the system
About 4 weeks
Standard format
For most products: the first map of critical areas arrives by week two or three, the final presentation in week four.
Up to 2 months
In-depth format
For large codebases or distributed teams: we observe more release cycles and a longer change history, because in systems like these the debt only shows itself over time.
What you get
The prioritised debt map
Every critical area with its risk, change frequency and business impact, plus one of four actions, in the order you should tackle them.
An executive summary for management
A document that translates the debt into consequences for the roadmap, for decision-makers who won't be reading the code.
A 90- and 180-day action plan
The order in which to tackle the areas, including the ones to leave as they are, and the signals to watch to see whether the plan is working.
What the debt map looks like
An example based on a hypothetical e-commerce business. Each row is an area of the system; the columns show how risky it is to touch, how often it gets touched and how much it costs the business; the last one says what to do about it.
| Area | Risk | Change frequency | Business impact | Action |
|---|---|---|---|---|
| Shipping managementEvery new carrier runs through here, and every change breaks some edge case | High | High | High | Refactor first |
| Core system integrationFragile, but only changes once or twice a year | High | Low | Medium | Contain it |
| Order flowChanges every sprint, and hardly any tests describe its behaviour | Medium | High | High | Test, then refactor |
| Historical reportingOld, complex code, but stable and away from where the product is growing | Low | Low | Low | Leave it as it is |
- Refactor first
- Where risk, change frequency and impact all add up: every week you wait costs you
- Contain it
- You isolate the area behind a clear boundary, so its debt stops spreading to the rest of the system
- Test, then refactor
- Where the code changes often but no test pins down its behaviour: characterisation tests describing how it works today come first, then refactoring with a safety net
- Leave it as it is
- Known, stable debt, far from the roadmap: stepping in would cost more than it saves
The debt you can leave alone
Not all debt needs paying off. A complex module that hasn't changed in years and sits away from where the product is growing costs little as long as it stays still; refactoring it on principle just spends the team's time for no return.
That's why one of the actions on the map is “Leave it as it is”, and why the first question we ask about every area is how much the next change you'll need to make there will cost. Knowing what not to touch frees up time and attention for the two or three areas that are really holding the roadmap back.
What this assessment doesn't include
A static analysis tool report, with hundreds of findings and no order to them
A judgement on people: debt almost always comes from sensible decisions made in a context that has since changed
An eighty-page document nobody reads after the presentation
A rewrite as a foregone conclusion: we only recommend one when the criteria actually justify it
Lock-in: the plan is written so your own team can carry it out without us
Evaluating software that isn't yours yet, for an investment or an acquisition? That's a tech due diligence, with different questions and a different timeline. What is a tech due diligence
After the assessment, three paths
The map stands on its own even if we don't keep working together. Which path to take depends on how much debt there is and where it sits, and you decide with the map in front of you.
Your team takes it from here
When the debt is contained and your team has the time and the skills
The 90- and 180-day plan is built to be run by your own team: priorities, actions and the signals to watch are already written down.
Targeted Intervention
When a single bottleneck is blocking everything else
A short, focused intervention on that one bottleneck, working in the code alongside your team, without committing to a wider programme.
How Targeted Intervention worksLegacy code refactoring programme
When the debt is widespread and holding the roadmap back on several fronts
An incremental programme of work on your codebase, with no full rewrite. The assessment tells you which approach fits: a small dedicated team working with your developers when the damage is serious, opportunistic refactoring alongside ongoing development when it is contained.
How the refactoring programme worksWhere this way of working comes from
At SureVIVE, software that coordinates rescue missions and runs around the clock, growth was blocked by technical debt: an architecture no longer fit for purpose and pockets of legacy code were slowing the system down in several places. The work started with an analysis done together with the team, covering the software's health and the dynamics of the organisation.
That analysis led to a refactoring programme that cleared the way just ahead of the features that depended on it, without becoming a separate workstream: technical debt fell by 15%, and features that had been out of reach became possible to build.
Frequently asked questions
- Do we need to give you access to the code?
- Yes, to the repository and its change history: without the real code the assessment would turn into a questionnaire, which is exactly what we want to avoid.
- How long does it take?
- The standard format takes about four weeks, with the first map of critical areas by week two or three. For large codebases or distributed teams there's an in-depth format, up to two months, that observes more release cycles and a longer change history.
- Which technologies do you work with?
- We're language-agnostic: we work with the stack you already have and adopt the tools your team already uses. Change history, coupling, testability and release flow can all be read in any stack.
- We already use SonarQube or CodeScene: do we still need this?
- Those tools tell you where the code is complex or changes often, and their data is useful to us. They don't tell you which debt is holding back the business, which you can leave alone, or in what order to tackle it: that's what the interviews, reading the code together with the team and knowing the roadmap are for.
- What's the difference between a code audit and a technical debt assessment?
- A code audit checks quality against rules and standards and produces a list of problems. A technical debt assessment starts from the same code but answers a different question: which debt is slowing down the changes that matter for the business, and in what order to deal with it. That's why it cross-references the code with the change history and with interviews with the team. If you're looking for technical debt consulting or an assessment, this is usually where it starts.
- What happens if the debt is everywhere?
- It's rare for debt to cost the same everywhere. Usually a handful of areas account for most of the friction, because they're the ones that change most often; the map exists precisely to separate them from the rest and decide where to start.
- Does this make sense before deciding on a rewrite?
- That's exactly when it matters most. A rewrite only makes sense in a handful of cases, for example technology that no longer gets security updates, or coupling so tight that no part can be isolated. The assessment tells you whether your system is one of those cases, or whether incremental refactoring gets there sooner and with less risk.
- How is this different from tech due diligence?
- Tech due diligence is for investors or acquirers evaluating software they don't own yet. A technical debt assessment is for teams that already build the software and want to know where to step in to make it easy to change again.
Before you commit
A free first call
Tell us about your system and what's holding it back, and we'll tell you honestly whether an assessment is right for you and in which format; sometimes the answer is that you don't need one.
Book the first callA self-assessment you can run right now
The Consistency Impact Calculator estimates the economic impact of misalignment between business, team structure and software: a first order-of-magnitude figure for what the slowdown is costing you.
Open the Consistency Impact CalculatorRelated problems
These warning signs tend to show up together. Explore the related topics.
Further reading in Learn
Articles by our team that look closely at the issues behind this challenge
How to measure technical debt: from architecture to workflow
Measuring technical debt isn't about installing SonarQube. It's about understanding where the system resists the changes the business needs. A practical guide to the metrics that matter — and the ones that distract.
The signs of technical debt: in the code, the team and the business
Technical debt sends out clear signals before it turns into an emergency. Many of them get read as people or process problems. This guide translates them into what they really are: symptoms of a software structure that can no longer keep pace with the organisation running on it.
Cost of change in software development: why it keeps growing
As software grows, changing the product gets harder and harder. The cost of change is one of the clearest signs that architecture, organisation and delivery have stopped evolving together.
Technical debt: an introduction for the C-suite
A five-part guide to technical debt for CTOs and CEOs: what it is, how it builds up, the warning signs, how to measure it and how to reduce it.
Request a technical debt assessment
We start with a free call: we get to know your system and agree the format and scope together