The conversation happens on a Tuesday. An engineer says the codebase has significant technical debt. The founder hears: some code is messy and we want time to clean it up. What the engineer means is: we are paying a compounding tax on every feature we ship, and at our current trajectory that tax will consume the majority of the engineering budget within two quarters.
These are not the same statement. The first is a preference. The second is a business risk. The reason technical debt conversations go badly is that engineers speak in the first language and founders hear the second as the first. Nothing useful gets decided.
We have watched this dynamic play out across enough teams to have a strong view on it: technical debt is a financial concept dressed in engineering vocabulary. Once you translate it properly, the decisions become straightforward. Until you do, they stay contentious.
Technical debt is not untidy code. It is a bet you made earlier that now has a carrying cost. Like financial debt, it is sometimes the right call. Like financial debt, it compounds if you ignore it.
The compound interest model
Every codebase carries some amount of debt: shortcuts taken under time pressure, abstractions that were correct at the time and are now wrong, dependencies that were never upgraded, test coverage that was deferred. None of these are free. Each costs engineering time on every feature that touches it: extra hours to understand the system, extra hours to work around the bad abstraction, extra hours debugging the failure mode nobody documented.
At low debt levels, the cost is a rounding error. At medium debt levels, it is a visible drag on velocity. At high debt levels, it is the dominant cost of the engineering organisation. The curve is not linear.
Illustrative velocity at sprint 12, relative to sprint 1, by debt level:
The chart above is illustrative. The shape is not. We have seen high-debt codebases where engineers estimate three-day tasks that take three weeks, not because the engineers are wrong but because every change requires understanding and working around a system nobody fully understands anymore.
How to measure your velocity tax
The velocity tax is the simplest metric: what percentage of engineering time is spent on work that would not be needed in a clean codebase? You can measure it by asking engineers to flag, for one sprint, every hour spent on: understanding legacy behaviour before writing new code, working around known-bad abstractions, debugging failures caused by missing documentation or test coverage, and fixing regressions caused by entangled dependencies.
In a low-debt codebase, this number is under 10%. In a medium-debt codebase, 20 to 35%. In a high-debt codebase, we have seen it exceed 50%.
| Debt level | Extra hours/sprint (illustrative) | Annual cost at €120/hr (illustrative) |
|---|---|---|
| Low | ~2h per engineer | ~€12,000 per engineer |
| Medium | ~8h per engineer | ~€50,000 per engineer |
| High | ~20h per engineer | ~€125,000 per engineer |
All figures are illustrative estimates only.
Multiply the per-engineer annual cost by your engineering headcount and you have a carrying cost figure you can put in front of a board. The purpose is not to be precise; it is to make the invisible visible.
The three debt traps
Funded startups fall into one of three patterns, usually within six months of their Series A when the hiring curve steepens.
The indefinite deferral. The team knows the debt exists and agrees it should be addressed, but there is always a feature that is more urgent. Debt accrues. Velocity falls. New engineers arrive and slow down further because onboarding in a high-debt codebase is long. The team starts missing commitments it used to hit easily, and the conversation becomes political.
The misallocated sprint. The team books a "tech debt sprint" every quarter and feels good about it. But the sprint addresses cosmetic issues rather than the structural debt that is actually causing the velocity drag. Velocity does not improve. The business concludes that debt work does not produce results, and stops approving it.
The premature rewrite. The team convinces itself that the only solution is to rebuild from scratch. Work stops on new features. The rewrite takes three times longer than estimated. The new codebase ships with a different set of problems. The business loses six months it cannot recover.
The rewrite question
The rewrite question is almost always the wrong question. The right question is: which specific parts of the system are causing the most velocity drag, and what is the minimum intervention that removes that drag?
| Option | When to choose | Warning signs |
|---|---|---|
| Rewrite | The system's fundamental design is incompatible with current requirements; every new feature requires changing core abstractions | The team is frustrated and the rewrite is the proposed solution to frustration, not to a specific constraint |
| Refactor | Specific subsystems are slowing a known set of changes; you can name the three files that cause 80% of the pain | The scope keeps expanding; "while we are in here" becomes the plan |
| Live with it | The affected subsystem is stable and rarely touched; debt is in non-critical paths | The subsystem is on the critical path for the next six months of roadmap |
Incremental improvement beats the big rewrite in almost every case we have seen. The exception is when the data model is structurally wrong and cannot be fixed without migrating data. For a related framing on minimum-viable technical decisions, see our piece on language choice.
How to talk to your board
Boards do not fund tech debt work. They fund business outcomes. The framing that works is not "we need to clean up the codebase" but: "our current architecture is costing us X engineering hours per sprint and blocking us from shipping Y. Here is the investment required to remove that constraint, and here is what velocity looks like after."
Three numbers help: the current velocity tax (measured, not estimated), the projected impact on delivery timelines for the next two quarters, and the estimated cost of the paydown work. If the paydown cost is less than two quarters of carrying cost, the ROI case makes itself.
What a paydown plan looks like
A paydown plan that works has four properties. It is specific: named systems, named engineers, named dates. It is measurable: velocity before and after, not a subjective sense of the codebase being cleaner. It is bounded: a defined scope that does not expand mid-execution. And it is parallel: debt work happens alongside feature work, typically at 20 to 30% of engineering capacity, not in dedicated sprints that pause product delivery.
The last point is the one most teams resist. It feels wrong to ship new features on a codebase being refactored underneath them. In practice, the alternative is worse: dedicated debt sprints create pressure to finish quickly, which produces shallow fixes. Sustained 20% allocation produces better results with less disruption.
The conversation about technical debt is ultimately a conversation about how your team works, not about the code. Teams that address it well treat debt as a standing concern, measured and managed like any other cost of running the business.