Two Types of Technical Debt

Ward Cunningham, who coined the term, described technical debt as a deliberate metaphor: you borrow against future quality to ship faster now, and you pay interest on that debt in the form of slower future development until you pay it down.

This metaphor captures intentional debt. But most engineering discussions conflate two very different things:

Intentional debt: "We're using a simple file-based storage for now to ship in two weeks. We'll migrate to a proper database when we validate this feature." Rational decision. Documented. Has a plan.

Unintentional debt: Code that nobody planned to be messy — it just got that way through accumulated hacks, unclear ownership, poor documentation, and absent tests. No plan to fix it. Often nobody even knows it's there until it breaks.

The first type is often the right call. The second type is what actually kills engineering velocity.

The Interest Rate Problem

Technical debt accrues interest in a specific way: every new feature that touches the debt-laden area costs more to build. The messier the code, the longer it takes to understand, modify, and test.

Signs your debt interest is too high:

• A feature that should take a day takes a week
• Engineers are afraid to touch certain parts of the codebase
• Bug fixes regularly introduce new bugs
• Onboarding new engineers takes unusually long
• You need to schedule large "refactoring sprints" to fix accumulated problems

When these signs appear, your debt isn't just a quality problem — it's a velocity and business problem.

When to Live With Debt

At the MVP and early growth stages, some debt is not just acceptable — it's correct.

Live with debt when:

• You're validating whether a feature is worth investing in. Don't build beautifully for features you might throw away.
• The area is stable and won't be changed for the foreseeable future. Debt in code that nobody touches costs nothing.
• The time saved by cutting a corner now is worth more than the time you'll spend fixing it later, given your runway and market window.
• You're confident you understand the cost and have a plan to address it.

The key habit: document the debt when you create it. Add a comment in the code, create a ticket in your backlog, or note it explicitly in the PR. "TODO: This needs a proper caching layer when we hit 10K users." This transforms unintentional debt into managed intentional debt.

When to Pay Down Debt

Pay down debt when the interest rate exceeds the cost of repayment. Specifically:

Before scaling. Debt that is manageable at 100 users becomes critical at 10,000. Performance shortcuts, database bottlenecks, and missing caching layers need to be addressed before you hit the scale that exposes them.

Before a new team member joins. If onboarding requires extensive tribal knowledge about why the codebase works the way it does, that's a debt that's actively costing you.

Before building on top of it. If a messy component needs a major new feature, that's the moment to refactor — not before (speculative cleanup) and not after (compounding the problem).

When the area has active bugs. Areas with high bug rates usually have high debt. Fixing bugs on top of messy code is inefficient. Refactor the area, then fix the bugs.

How to Budget for Debt Repayment

The "20% rule" is common: dedicate 20% of each sprint to technical debt work. This prevents accumulation from getting out of hand while ensuring feature velocity doesn't stall.

In practice, the percentage varies by team stage:

• Pre-PMF: 5–10%. You need to ship and learn.
• Post-PMF, pre-Series A: 15–20%. You're starting to build systems that will last.
• Scaling team: 25–30%. The cost of debt grows with team size.

The important thing is having an explicit budget rather than letting debt work compete with feature work on an ad-hoc basis. Debt work usually loses that competition until it's a crisis.

The Conversation With Stakeholders

Non-technical founders often struggle to explain debt priorities to investors or boards. A useful framing: "We've identified three areas of the codebase that are currently limiting our ability to ship new features at our target velocity. Addressing these will increase our engineering capacity by approximately 20% going forward."

Quantify where you can. "This area takes engineers 3x longer to work with than it should" is more compelling than "the code is messy." Track feature lead times before and after major debt repayments to demonstrate ROI.

Technical debt isn't a sign of a bad engineering team — it's a sign of a team that was shipping quickly. The best teams manage it proactively rather than treating it as something shameful to hide.