Assessing technical debt

Every company that moved fast has technical debt. It is the quick solutions chosen to release on time: the quick fix instead of the clean one, the feature added on top instead of designed into the system, the cleanup postponed to meet a deadline. Often it is a sign of a team that made sensible trade-offs to get to market. The problem is only the ongoing cost of those quick solutions, which grows until someone fixes them.

What is technical debt, and where did the term come from?

Technical debt is the extra cost of maintaining a system that comes from choosing the quick solution over the better one. Ward Cunningham created the comparison in 1992 while explaining to his employer why a rewrite was needed, and his explanation still contains the whole idea: releasing first-time code is like going into debt, and a small amount of debt speeds development so long as it is paid back promptly with a rewrite. He added that the danger comes when the debt is not repaid, because every minute spent working around imperfect code counts as interest on that debt.

That explanation is why the review treats debt as a number rather than a mark against the team. As we have argued, execution speed is the moat, and speed sometimes means choosing quick solutions on purpose and accepting extra work later. So the question is "is there debt that will slow or stop the growth in the thesis, and does the team have a plan to handle it", which is the approach the main guide uses for the whole review.

Reveneau's technical debt assessment asks the team to list its own debt, and where it is, before the reviewer does, because a team that can point to its worst debt and say why it took the shortcut has a plan waiting to be funded, and a team that cannot see its own debt cannot plan for what it cannot name.

Why does every codebase have debt, and why is that acceptable?

Every codebase has debt because software is built under deadlines by people who learn as they go. A review that criticises a company for having debt is measuring the wrong thing, the same as criticising it for having outages. Taking a shortcut to validate a product, with a plan to fix it once the product shows it works, is good judgment.

Stripe's 2018 survey of developers and executives, by its own account, found the average developer spending 13.5 hours of a 41.1-hour week on technical debt and 17.3 hours on maintenance work such as debugging and refactoring. Those are vendor figures from a single survey, but they give a reference point: a team that reports numbers in that range is describing a normal codebase. A team that reports far higher numbers, or that cannot say, is describing something else.

How do you tell healthy debt from dangerous debt?

Acceptable debt is limited to one area, known, and cheap to maintain. Dangerous debt spreads, is often hidden until you look, and makes the whole system slow and risky to change. Martin Fowler's technical debt quadrant, published on 14 October 2009, gives a reviewer a way to sort what the team describes.

Quadrant	Fowler's example	What it looks like in diligence	How to treat it
Prudent and deliberate	"We must ship now and deal with the consequences"	The team can name the shortcut, the reason, and the plan to fix it	Price the repair; this is normal
Prudent and inadvertent	"Now we know how we should have done it"	Design lessons learned after the fact by a good team	Expect it; Fowler calls it inevitable for excellent designers
Reckless and deliberate	"We don't have time for design"	Shortcuts with no plan and no owner, across the codebase	A team and culture finding, priced with the repair
Reckless and inadvertent	"What's layering?"	Messy code from people who did not know better	The costly category; the fix is usually people as much as code

The quadrant matters because the same amount of debt costs different amounts depending on which category it is in. Prudent debt has an owner and a plan. Reckless debt has neither, and its cost keeps growing. Ask the team to place its own worst debt in one of the four categories and listen to the reasoning; the placement tells you about the debt and the reasoning tells you about the team, which is why the assessing the engineering team page and this one are read together.

Another sorting question is where the debt is. Debt in a minor feature is cheap to ignore. Debt in the core system that everything depends on is expensive, because it adds cost to every future change. Ask where the debt is, as well as how much there is.

What are the signs that debt has started to slow the team down?

The clearest sign is a team that releases more slowly over time. When features that used to take days start taking weeks, and when small changes keep breaking unrelated things, the debt has reached the point where every change to the code is hard. This connects to assessing code quality, because debt is the main thing that makes code hard and slow to change, and the DORA delivery metrics on that page are the way to see it in numbers.

Ask for the trend rather than the current state. DORA's change lead time (the time from a commit to production) rising over twelve months, deployment frequency falling, and change fail rate (the share of deployments needing immediate intervention) rising is the typical pattern of debt slowing the team down. A company can still be growing from past work while this happens, which is why it is easy to miss. Ask the team directly: is it getting harder to release changes, and which part of the code is hardest to change. An honest team will tell you exactly where.

How do you size debt on a deal timeline?

You cannot count technical debt precisely, but you can size it well enough to price in a few structured conversations.

1. Ask for the three-month question. What would the team fix if it had three months to do nothing but fix debt? The answer tells you where the worst debt is and whether the team understands its own system.
2. Ask for the split of time. How much of the team's effort goes to working around problems in the codebase rather than building new things? Compare the answer with the pull request history: a high share of "fix" and "hotfix" changes against "feature" changes is the same answer in data.
3. Ask for the debt register. Does one exist, who owns it, and when was it last updated? A register that exists and is out of date is a finding; one that is used in planning is a strength.
4. Ask how debt repair is scheduled. A healthy organisation fixes debt deliberately, in small steps, alongside new work. A risky one lets it grow until it becomes a crisis. Ask whether debt repair is part of how the team plans its work or something it never gets to.
5. Check the core. Take the single most important service and ask how long a small change there takes, who can make it, and what has broken there in the last year. Debt in the core is the debt the thesis pays for.

The founder-side view of the same questions is in how to prepare for technical due diligence, and the technical due diligence questionnaire includes them as a request list.

What is agent debt, and why does it appear in AI-written codebases?

Agent debt is technical debt that accumulates when code is generated faster than anyone reads it. It is the modern form of Fowler's reckless and inadvertent category: nobody chose the shortcut, and nobody knows it is there. Google's October 2024 DORA report associated a 25 percent increase in AI adoption with a 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability, which is what debt slowing teams down looks like in survey data.

In a generated codebase the specifications are often the only surviving record of intent, so ask whether they exist and are kept up to date. Ask what checks ran on generated code before it merged, and whether an evaluation suite covers the behaviour the specification promised. The agent debt when generation outpaces review page in the evals guide explains how it happens, and the diligence on an AI-written codebase page covers the review.

How do you price it against the thesis?

Once you understand the debt, price it as work. Some of it you will fund on purpose, because fixing it gives the team the speed the thesis needs. Some of it you will accept, because it does not affect the parts of the system the growth depends on.

Finding	What it costs	Where it goes
Known, contained debt with an owner and a plan	The plan, as written	First-hundred-days plan
Debt in the core service, team can name it	Months of focused work by the senior people	Price, and the first-year plan
Releases slowing each quarter, team cannot say why	Discovery first, then a repair the review cannot size yet	Price as unmeasured risk; a warning sign
Honest answer is a partial rewrite	A rewrite of the affected parts, with the product still running	Price and timeline, and a team question
Team cannot see its own debt	Cannot be planned by this team	Terms, and a team finding
Generated code with no specification and no evaluation suite	Specification recovery, then an evaluation suite	Price as unmeasured risk

The judgment is whether the debt is a manageable cost or a structural problem. Manageable debt is a known amount of cleanup by a team that understands it. A structural problem is debt so large that the honest answer is a partial rewrite, or debt the team does not see. A strong senior team turns debt into a manageable cost; a weak team lets it become the thing that stops the company. For a fund with several companies carrying debt at once, the technical debt across a portfolio page covers how to prioritise, and how to take over a codebase you did not write covers what the repair work looks like for the team doing it.