Technical debt is the most abused metaphor in software — used to excuse everything and explain nothing. The finance analogy actually works if you take it seriously: debt is leverage (speed now, interest later), and like financial debt, the question is never "is debt bad?" but "is this loan funding growth or lifestyle?" Here is the founder's field guide.
Good debt, bad debt
Good debt is deliberate: shipping the MVP with a hardcoded config because validating demand this month matters more than elegance (MVP discipline), skipping edge cases the market has not proven exist. It is logged, visible, and repayable.
Bad debt is accidental: no tests because nobody insisted (the testing floor), copy-pasted logic in nine places, dependencies three years stale (deferred maintenance compounding), tenant checks in app code instead of the database. Nobody chose it; everyone pays it.
How the interest shows up in your business
Feature velocity decays quarter over quarter (the same team ships less), estimates inflate ("two weeks" becomes "it depends what it touches"), every release breaks something old, onboarding new developers takes months, and eventually someone proposes The Rewrite — the debt spiral's terminal event, which usually fails too. If your roadmap feels like wading, you are paying interest.
Managing it without reading code
- Make debt visible. A debt register next to the feature backlog — named items, business impact, rough repay cost. What is invisible is unmanageable.
- Budget repayment structurally. 15–20% of engineering capacity, every sprint, forever — not "when things calm down" (they never do). This is the preventive slice of maintenance by another name.
- Repay along the roadmap. Clean the modules you are about to build in; debt in code you never touch charges no interest.
- Watch the metric that matters: cycle time from idea to production, quarter over quarter. Rising cycle time on a stable team is the debt bill arriving.
The vendor angle
Fixed-price builds create rush-debt incentives; counter with acceptance criteria that include tests and structure, code review rights, and the four questions from the red-flags guide. Cheap bids are usually debt disguised as savings — you pay the difference later, with interest.
Inherited a codebase that feels like wading? We audit before we quote — a debt map with business impact, then honest options: pay down, contain, or (rarely) rewrite.
Frequently asked questions
What is technical debt in business terms?
Engineering shortcuts that trade speed now for interest later. Good debt is deliberate, logged, and repayable — shipping fast to validate demand. Bad debt is accidental — missing tests, stale dependencies, copy-pasted logic — that nobody chose and everyone pays.
How do I know if technical debt is hurting my business?
The interest signals: feature velocity decaying on a stable team, inflating estimates, releases breaking old features, months-long developer onboarding, and rising idea-to-production cycle time. When someone proposes The Rewrite, the spiral is terminal.
How much engineering time should go to debt repayment?
15–20% of capacity, every sprint, structurally — not 'when things calm down.' Repay along the roadmap: clean modules you're about to build in; debt in untouched code charges no interest.
Do fixed-price projects create technical debt?
The incentive exists — rushing creates invisible debt. Counter it with acceptance criteria that include tests and structure, code review rights, and vendor-vetting questions. Suspiciously cheap bids are usually debt disguised as savings.