Tech debt gets a bad rap. Every engineering blog wants you to believe that any shortcut is a cardinal sin that will doom your startup.
That's nonsense.
Tech debt is a tool. Like any tool, it can be used wisely or recklessly. The key is knowing the difference.
Good Debt vs. Bad Debt
Just like financial debt, tech debt comes in different flavors:
- Strategic debt - Intentional shortcuts to hit a market window. You know exactly what you're trading off.
- Tactical debt - Quick fixes to unblock shipping. Documented, planned to fix later.
- Accidental debt - Shortcuts you didn't realize you were taking. Usually from inexperience.
- Reckless debt - "We'll fix it later" without any plan. This is the killer.
“The startup that ships with tech debt beats the startup that never ships because they're still refactoring.”
When to Take on Debt
Take on tech debt when:
- You're validating a hypothesis and the code might be thrown away anyway
- There's a clear market window that won't wait for perfect code
- The debt is isolated and won't spread to other parts of the system
- You have a concrete plan to pay it back
When to Pay It Back
Pay back tech debt when:
- It's slowing down every new feature you try to build
- It's causing bugs that affect users
- It's making onboarding new developers painful
- You're about to build something major on top of the shaky foundation
The 20% Rule
Here's our rule of thumb: allocate 20% of every sprint to paying down tech debt. Not 0% (debt accumulates). Not 50% (you'll never ship). Twenty percent.
This keeps the codebase healthy without sacrificing velocity. It's the sustainable pace that lets you ship fast for years, not just months.
The Bottom Line
Tech debt isn't inherently bad. Unmanaged tech debt is bad. Know what debt you're taking on, why you're taking it on, and when you'll pay it back.
Then ship the damn thing.
Share this article