What Is Technical Debt?

Technical debt is the future cost of shortcuts taken in code today — every "we'll fix it later" decision that makes the next change slower and riskier. Like financial debt, the shortcut buys speed now, but you pay interest on it with every feature you build afterward.

The metaphor comes from programmer Ward Cunningham, who described shipping imperfect code as borrowing against the future: you can move fast on a first version, but the interest is real, and it comes due whenever someone has to extend or fix the affected code.

How technical debt works

A single shortcut is cheap and often correct. The problem is compounding. Ten shortcuts in the same codebase start interacting in ways nobody planned. To add a new feature, an engineer first has to understand and work around all ten. Velocity drops, bugs multiply, and people quietly avoid the messiest files because every edit feels like defusing something.

That is the "interest": not the original shortcut, but the recurring tax every later change pays. Debt left invisible long enough turns a feature request into a rewrite.

Types of technical debt

• Intentional — "Ship now, refactor after we validate." A reasonable MVP tradeoff when you know the bill and plan to pay it.
• Accidental — bad patterns introduced by inexperience or deadline pressure, with no plan to repay.
• Bit rot — code that was correct when written but drifted out of step as the system, dependencies, or requirements changed around it.

Intentional debt is a tool. Accidental debt and bit rot are leaks.

Good debt vs. bad debt

Common SaaS debt that hurts most

Some shortcuts are far more expensive to repay than others. In SaaS products, the recurring offenders are:

• No multi-tenancy from the start — retrofitting tenant isolation into a single-tenant data model is one of the most expensive rewrites there is.
• Missing or loose types — without something like TypeScript, whole classes of errors stay silent until they hit production.
• No tests on billing logic — every change near payments risks charging the wrong amount or breaking subscriptions.
• Hardcoded configuration — secrets and environment values baked into code break parity between dev, staging, and production.

When taking on debt is fine — and when it isn't

Reasonable: validating an unproven idea, hitting a real launch window, or stubbing a feature you expect to throw away. The rule is that it's a deliberate choice with a repayment plan attached.

Not reasonable: skipping tests on money-handling code, hardcoding things that obviously vary per environment, or copy-pasting a flawed pattern so it spreads. These compound fastest and are the hardest to unwind later.

Common mistakes

• Treating all debt as equal. A messy utility function and an untested billing path are not the same risk. Repay by impact, not by how ugly the code looks.
• Calling every refactor "tech debt." Cleanup you simply prefer is not debt; debt is a real, named cost that slows future work.
• Never scheduling repayment. Debt that is only ever discussed, never paid, becomes the rewrite you were trying to avoid.
• Hiding it. Undocumented shortcuts are the most dangerous kind, because the next person can't see the interest accruing.

A concrete example

A founder ships a booking app that assumes one business per database. It validates fast and gets customers — good intentional debt. Then a second client wants in. Now every query, every screen, and every billing record has to learn about tenants at once. Building multi-tenancy in from day one would have cost a little up front; retrofitting it after launch touches nearly the whole codebase. (For context, products like the BookBed booking SaaS plan for multi-tenant and integration concerns — such as bidirectional iCal sync — early, precisely because retrofitting them is the expensive path.)

Managing it deliberately

Good engineering isn't zero debt — it's choosing which shortcuts to take, writing them down, and paying them back before they compound. A recurring "tech debt" pass (for example, once a quarter) keeps small shortcuts from interacting into a rewrite. The worst outcome is debt that accrues invisibly until the codebase is too fragile to change safely.

Key takeaways

• Technical debt is the future cost of present shortcuts — speed now, interest later.
• The danger isn't any single shortcut; it's compounding when many interact.
• Intentional, documented, repaid debt is healthy. Invisible, accidental debt is what kills velocity.
• Prioritize repayment by business risk (billing, data isolation), not by which code looks ugliest.