01Measure
Repository history, complexity, coverage, build and lead times analysed.
You getA heat map of where change and complexity overlap.Modernize
Make the next change cheap again.
Technical debt is only a problem where it slows something down. We measure which parts of your codebase actually cost you delivery speed and defects, fix those, and leave the rest alone, because a tidy module nobody touches is worth nothing.
What the assessment measures
- 01Assessment2–3 weeks, fixed price
- 02Measured onChange frequency, defect density, build and lead time
- 03Delivery styleAlongside feature work, never a freeze
- 04PrioritisationBy cost of delay, not by lint count
- 05EvidenceBefore-and-after metrics, not opinions
- 06HandoverYour team keeps the tooling and the standards
The distinction that saves money
Ugly code you never touch is not debt. It is just ugly.
Most technical debt programmes fail by trying to fix everything. A static analysis tool reports eleven thousand issues, a quarter is spent driving that number down, and delivery speed does not change, because the issues were spread evenly across code that nobody modifies.
Debt only costs you where change happens. A module that has not been edited in four years can be as messy as it likes; it is stable, it works, and touching it introduces risk for no return.
So the first question is not “where is the code bad?” but “where is the code bad and changing often?”. That intersection is small, usually five to ten percent of a codebase, and it is where essentially all of the pain lives.
We find it with evidence, not instinct: version-control history, defect data, build times and lead times, cross-referenced against complexity. The output is a ranked list where each item has a cost of delay attached.
How we find what is worth fixing
01Mine historyWhich files change most, and change together.
02MeasureComplexity, coupling, test coverage, build time.
03CorrelateOverlay defects and incidents onto that map.
04RankScore by cost of delay, not by rule violations.
05FixRefactor behind tests, in small reversible steps.
06ProveRe-measure lead time and defect rate afterwards.
Where the money is
Only one quadrant is worth paying to fix.
We plot every module on these two axes using version-control history and complexity analysis. The answer is usually five to ten percent of the codebase.
How often it changes
Changes often · simple
Leave it — it is working
Frequently edited and easy to edit. This is what healthy code looks like; there is nothing here to buy.
Changes often · complex
Fix this first
The intersection where essentially all your delivery pain lives. Every estimate that surprised you traces back to this quadrant.
Rarely changes · simple
Ignore entirely
Stable, readable and untouched. No action, no budget, no discussion.
Rarely changes · complex
Document, do not refactor
Ugly but stable. Touching it introduces risk for no return — write down what it does and leave it alone.
How complex it is
What debt looks like from the outside
Six symptoms that usually mean debt, not incompetence.
Leadership rarely sees code. It sees these, and they are reliable indicators of where the underlying problem is.
01
Estimates keep growing
The same size of change costs more each quarter, and nobody can explain why in terms the business accepts.
Symptom of coupling & missing tests
02
The same bugs return
A defect is fixed, ships, and reappears in another form two releases later.
Symptom of duplicated logic
03
Releases are events
Deployment needs a weekend, a runbook and several people on standby.
Symptom of manual pipeline & coupling
04
Only one person can touch it
There is a system, and there is the individual who understands it, and everyone knows who they are.
Symptom of knowledge concentration
05
Nobody will give a straight estimate
Every answer is “it depends what we find”, because it does.
Symptom of unreadable code paths
06
Testing takes longer than building
Manual regression dominates every release because automated coverage is thin.
Symptom of absent test strategyHow we work
Six rules we hold to while paying debt down.
Refactoring a production system is the easiest way to introduce defects. These are the constraints that keep it safe.
Tests before changes
If a module has no coverage, characterisation tests come first — capturing what it currently does, including the behaviour that looks wrong.
Behaviour is preserved exactly
Refactoring and feature change never travel in the same commit. When something breaks, you need to know which of the two caused it.
Small, reversible steps
Many small merges instead of one long-lived branch. A refactor branch that lives for six weeks becomes its own migration project.
Feature work never stops
Debt reduction runs as a share of capacity alongside delivery. A freeze buys goodwill from engineers and destroys it with everyone else.
Standards get automated
Anything agreed becomes a linter rule, a CI check or a template. Conventions that rely on memory decay within two quarters.
Results are measured
Lead time, change failure rate and build duration are recorded before and after, so the investment can be defended with numbers.
How we deliver
Evidence, then a plan, then measurable change.
02Interview
Conversations with the engineers who live in the code and the people waiting on it.
You getA ranked list of pain points, with the disagreements recorded.03Prioritise
Each candidate scored on cost of delay against effort to fix.
You getA costed backlog you could hand to your own team tomorrow.04Pay down
The top items fixed behind tests, in small merges, alongside your delivery.
You getWorking code, plus the automated checks that stop the debt returning.05Hold the line
Standards enforced in CI, with debt tracked as a normal backlog item.
You getTrend reporting on lead time, defect rate and build duration.Questions worth asking
Before you fund a clean-up.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
How do we justify this to a board that wants features?
By framing it as delivery speed, not code quality, and by bringing numbers. Boards do not fund tidiness, and they should not. They will fund a case that says a specific change now takes six weeks and would take two if three named modules were fixed, at a cost of X. That requires measuring lead time before you start, which is the main reason we insist on the assessment phase — without a baseline, the improvement is unprovable and the budget will not be renewed. The other argument that lands is risk concentration: the fact that one person can safely modify a business-critical system is a board-level issue even when delivery speed is acceptable.
Will you rewrite our code in your own style?
No, and we would be doing you damage if we did. We adopt your conventions unless they are the actual problem, and when a convention does need to change we agree it with your engineers and then encode it in tooling so it applies to everyone including us. The failure mode here is familiar: a supplier leaves behind a codebase in a house style nobody internal recognises, and the debt you paid to remove returns as unfamiliarity. Your team reviewing our pull requests from the first week is the safeguard, and it is not optional in how we work.
Our system is so bad that a rewrite feels easier. Is it?
Very occasionally, and much less often than it feels. A rewrite restarts from zero knowledge of everything the original quietly handles, and the second system usually takes longer than estimated while the first still needs maintaining throughout. The honest test is whether the business model the system encodes has changed — if it has, rebuild; if the logic is still right and only the implementation is painful, incremental repair is faster and far less risky. We will assess and tell you which, including when the answer is the more expensive one.
Related capabilities