The technical debt you should keep
Not all technical debt is worth paying down. A framework for classifying debt by interest rate, with the categories that are safe to carry indefinitely.
Technical debt is a useful metaphor that teams almost always use wrong. The metaphor's whole point is *interest* — how much the shortcut costs you per unit of time. Debt with no interest is free money.
Debt with high interest — pay it now
- Anything that slows the deploy loop. Flaky tests, 20-minute builds, manual release steps. This charges interest every single day, to everyone.
- Missing observability. You pay for it every incident, at the worst possible moment.
- Auth and data-access shortcuts. The interest here is a breach.
- A data model that is wrong. Every new feature pays a tax.
Debt with no interest — keep it
- Ugly code in a stable file nobody touches. The billing edge case written in 2024 that has not changed since. Leave it.
- Duplication across two features that genuinely differ. Premature de-duplication is worse debt than duplication.
- Old-but-supported dependencies. "Two majors behind but patched and working" is not an emergency.
- Inconsistent styling in internal tools. Nobody is converting on your admin panel.
The test
Ask: "if we do nothing about this for six months, what does it cost?" If the answer is a specific recurring number of hours or a specific risk, schedule it. If the answer is "it would annoy me", write it down and move on.
Making it visible
Keep one list with two columns: interest-bearing and dormant. Review it monthly. Move items between columns as the product changes — dormant debt wakes up the moment a roadmap item touches that code, and that is the right moment to pay it.
The goal is not a clean codebase. The goal is a codebase where the next feature is cheap.
Common questions
- How do I explain keeping technical debt to a non-technical founder?
- Use the interest metaphor honestly: some shortcuts cost more every week you keep them, others cost nothing until you touch that code again. Pay down the first kind on a schedule; leave the second kind until it blocks something.
Need this built rather than read about?
I'm a solo developer who scopes, designs, builds and deploys the whole thing. Send a few sentences about your project and you'll get an honest read on scope, timeline and price — usually the same working day.
Oxymore is a one-person studio shipping MVPs, landing pages, React apps and Telegram bots for founders who would rather move than meet.
Last updated