The dominant narrative about technical debt is that it is bad and should be paid down. That framing is useful as a default and wrong as a universal rule. Not all technical debt is created equal. Some of it is the right strategic choice.
Here is how to tell the difference.
The original definition matters
Ward Cunningham, who coined the term, used it for code that was intentionally simplified to ship faster, with a plan to refactor once the design became clear. The metaphor was financial: you borrow capability now and pay interest in slower future development until you repay.
That definition is precise and rarely how the term is actually used. In practice, "technical debt" gets applied to anything an engineer wishes were different about the codebase: hasty code, missed abstractions, outdated libraries, complex legacy systems they did not write. Some of these are debt. Some are not.
The three categories
Deliberate, prudent debt. "We are shipping the simpler version now to validate the market. If it works, we will replace the prototype with the real thing." This is good debt. It moves the business forward, it has an explicit repayment plan, and the cost of being wrong is bounded.
Accidental debt. "We did not know the better way at the time. We do now." Mostly neutral. Worth paying down when you touch the code anyway. Not worth a dedicated cleanup project unless it is genuinely slowing down current work.
Negligent debt. "We knew the right way but skipped it because we did not want to do the work." Bad debt. Pay it down quickly. The longer it sits, the more downstream code is built on top of it.
The conversation should be about which kind. "We have technical debt" without distinguishing the kind is too vague to act on.
Debt that is actively good
A few specific cases where taking on debt is the right call.
Validating market fit. Before you know what you are building, building it well is wasted effort. The startup with the best-architected pre-PMF product almost never wins. Speed and learning beat code quality.
Customer-driven features in active discovery. If a feature is being shaped by 5 design partners and you are not sure which version they will actually use, building it scrappily with the explicit plan to throw it away is correct.
Time-sensitive opportunities. A competitor is launching next week. A regulation drops in 30 days. A partner deal closes if you can demo in a month. Speed has real strategic value that outweighs cleanliness.
Bridges during platform migrations. "We will run both systems for 6 months while we migrate" is intentionally messy code. The mess is the point.
Debt that is actively bad
Other cases where deferring quality compounds badly.
Authentication, authorization, and security. Cutting corners here creates incidents. Never the right tradeoff.
Database schema decisions. Schema is expensive to change. Get this right or pay for it later, often at a 10x multiple.
Anything that affects observability. Logging, metrics, traces, audit. The cost of adding these later is enormous. The cost of adding them now is small.
The boundaries between major systems. Internal APIs, event schemas, service contracts. These calcify. Get them right.
Anything customer data is stored in. Migrating customer data is high-risk and high-effort. Choose your storage carefully.
How to manage debt deliberately
The teams that handle technical debt well do three things.
Document it explicitly. When you ship a deliberate shortcut, write down what it is, why, and what would trigger repayment. This is how the original Cunningham metaphor was supposed to work.
Allocate explicit time for repayment. 10 to 20 percent of engineering capacity for tech debt and tooling work. Not "when we have time" (which never arrives). Calendar it.
Tie repayment to current work. The cheapest time to fix a piece of debt is when you are already in that code for another reason. Train the team to pay down debt opportunistically.
The conversation to have with non-technical stakeholders
"We have $200K of features in the backlog and we should spend a quarter on cleanup instead" is a hard pitch and usually the wrong frame. Better: "Feature X is going to take 6 weeks instead of 2 because of debt Y. Fixing Y costs 3 weeks but unlocks future features. Here is the math."
Tie debt repayment to specific business outcomes. Then the conversation is not engineering vs business, it is one form of business work vs another.
Debt slowing you down?
We help engineering teams categorize technical debt, prioritize what is actually worth fixing, and structure the work without stopping feature development.
Get an audit