The myth of zero technical debt
There's a persistent fantasy in engineering culture that the best codebases have zero technical debt. That every shortcut is a sin. That "doing it right" always means doing it thoroughly.
In a startup, this mindset will kill you. You'll ship perfect code to zero users while your competitor ships imperfect code to ten thousand.
Technical debt as strategy
The smartest engineering leaders we've worked with treat technical debt like financial debt — a tool with costs and benefits.
Good debt: accelerates learning
Taking a shortcut to ship a feature faster so you can validate whether users even want it? That's good debt. If the feature fails validation, you delete it. If it succeeds, you schedule the refactor.
Bad debt: accumulates silently
Skipping error handling, ignoring test coverage, copy-pasting instead of abstracting — these create compounding interest. Each new feature becomes slower to build because the foundation is crumbling.
Our framework for managing debt
The debt register
We maintain a living document that tracks every intentional shortcut. Each entry has: what we cut, why we cut it, the estimated cost to fix, and the trigger condition for when we must fix it.
Debt sprints
Every six weeks, we dedicate one sprint entirely to debt reduction. No new features, no stakeholder requests. Just paying down the highest-interest items from the register.
The 30% rule
In regular sprints, 30% of engineering capacity is reserved for non-feature work: debt, tooling, testing, and infrastructure. This prevents debt from compounding between debt sprints.
When to refuse debt
Some debts are never worth taking: security shortcuts, data integrity hacks, and anything that affects user trust. These aren't debts — they're liabilities with unlimited downside.
