What Is Technical Debt, and When Should You Pay It Down?

Technical debt is the gap between how your software is built and how it would need to be built to change easily. Like financial debt, it is not automatically bad - it is borrowed speed, and it charges interest.

The interest shows up as time. A change that would have taken a day takes three, because it has to be made in four places, and nobody is certain what else depends on it.

What it looks like from outside engineering

Founders rarely see technical debt directly. They see its symptoms, and usually attribute them to the team rather than the codebase.

• Estimates keep growing for features that sound similar to ones you already have.
• Every release breaks something unrelated to what changed.
• Only one person can safely touch a particular area.
• Small changes require a disproportionate amount of testing.
• Engineers start sentences with "we should really rewrite...".

If the same feature would have taken two weeks a year ago and takes six now, that difference is the interest payment.

Not all debt is the same

Lumping everything together is what makes these conversations unproductive. There are roughly four kinds, and they deserve different responses.

Only the last category justifies stopping feature work. The first three are handled by doing ordinary engineering carefully.

Where it comes from

Debt accumulates for reasons that were sensible at the time.

Deadlines are the obvious one: the shortcut that gets a release out is genuinely the right call when the alternative is missing a launch. Changing requirements are another - a data model designed for one product shape is carrying debt the day the product becomes something else, without anyone having made a mistake.

Turnover contributes more than people expect. Code written by someone who has left is harder to change not because it is bad, but because the reasoning behind it went with them.

And increasingly, generated code contributes: it is fast to produce and easy to accept without anyone forming a view on whether it fits the structure around it.

How to decide what to fix

The useful question is not "is this debt?" - most of a codebase is, by some standard. It is "is this debt costing us anything?"

Debt in code nobody touches costs nothing. An inelegant module that has not needed changing in two years can stay inelegant indefinitely. Debt in the area you ship to every week is expensive, and paying it down returns time immediately.

So the practical test has two parts: how often do we change this, and how much does each change hurt? Anything that scores high on both is worth fixing now. Anything low on either can wait, possibly forever.

Fix the debt that sits where you work, not the debt that offends you most.

What to do about it

Three approaches, in order of how often they are the right answer.

1. Fix it as you pass. When a feature takes you into a messy area, leave it slightly better. This handles most debt at almost no visible cost.
2. Schedule a specific fix. For a known problem with a known cost - a fragile payment path, a slow query - book it as work with a defined outcome, not "refactoring time".
3. Rebuild a subsystem. Only when a part of the system genuinely cannot carry what you need, and with a comparison of what maintaining it would cost instead.

Be wary of the full rewrite. It is almost always more expensive and slower than expected, and it reproduces the original's subtle behaviours only after painful rediscovery. Partial, deliberate replacement of a specific subsystem is nearly always the better trade.

Talking about it with your team

Engineers often raise debt in technical terms, which makes it sound like preference. The translation that makes it a business conversation is cost and risk.

Ask: what does this cost us per feature right now, what does it prevent us from doing, and what happens if we leave it for another year? An engineer who can answer those has identified real debt. One who cannot may be describing a style disagreement - which is fine, but it is a different conversation.

If you want an outside read on where a codebase actually stands, that is what our code audit.

Frequently asked questions