Technical Debt

Technical debt is the cost you agree to pay later in exchange for shipping sooner.

The metaphor is exact, and worth taking literally. You borrow speed today. You pay interest on it every sprint after — in features that take longer than they should, bugs that keep coming back, and the growing sense that nobody wants to touch a particular part of the system. Like financial debt, a sensible amount is a tool. Left unserviced, the interest eventually consumes everything you earn.

The part most people get wrong

Technical debt is not the same as bad code, and conflating the two leads to bad decisions.

Deliberate debt is a strategy. You're testing whether anyone wants the product — so you hard-code the pricing, skip the admin panel, and do onboarding by hand. That's not sloppiness. It's the right call, and an MVP that refuses to take on any debt is usually just a slow MVP.

The dangerous kind is unintentional debt: shortcuts nobody chose, taken because of time pressure, and never written down. Deliberate debt has a repayment plan. Accidental debt has a surprise.

The test isn't "did we cut a corner?" It's "did we decide to, and does anyone remember?"

How it shows up in the business

You'll usually feel technical debt before anyone names it. The signals are commercial, not technical:

• Estimates keep growing for changes that sound small
• The same bugs return after being fixed
• Releases get scarier, so they get rarer, so they get bigger, so they get scarier
• Onboarding a developer takes months
• One person is the only one who understands a critical system — and everyone knows who

That last one is the one that ends companies.

When to pay it down — and when not to

Not all debt is worth repaying. Debt in code that never changes is like a mortgage on a house you'll never sell: technically outstanding, practically irrelevant. Rewriting a stable, working, boring subsystem because it offends someone's taste is a genuine waste of money.

Pay down debt where it's charging you interest — in the parts of the system you touch constantly, where the slowdown is real and measurable. The question isn't "is this code good?" but "what is this specifically costing us, and how often?"

How we handle it

Untangling legacy systems is a core part of what we do. For FilmWaffle we migrated an ageing stack across languages and frameworks with zero downtime and no data loss in a six-hour window, then scaled it to handle 5 million views a month. For Kandor we joined as founding/fractional CTO, migrated the legacy platform and rebuilt it in eight weeks.

Neither was a rewrite for its own sake. Both were debt that had started charging real interest — and a plan to pay it off without stopping the business.