What is technical debt?

Why it matters

Every shortcut you take to hit a deadline borrows speed from the future. That can be a smart trade, you ship now and learn now, but the loan is real. As the debt builds, each new feature takes a little longer, breaks a little more, and frightens the team a little more. For a founder, the symptom is a product that once moved fast and now crawls, with no obvious reason why. The reason is usually debt nobody chose to pay back.

It is not the same as bad code

A messy codebase is just sloppy. Technical debt is a deliberate trade: you knew the cleaner way and chose the faster one on purpose, to ship and learn sooner. That is a legitimate call, especially for an early MVP where the goal is to test an idea, not to build a cathedral. The discipline is writing the debt down, naming it, and scheduling the cleanup, so a conscious shortcut does not quietly rot into a mess no one understands.

The common mistake (in both directions)

The usual failure is never paying it down: you keep borrowing until the interest, slow changes and constant bugs, eats your whole engineering budget. The opposite failure is over-engineering early, polishing and future-proofing code for a product that has not yet proven anyone wants it. Both waste money, and so does the quiet third path: letting scope creep pile on rushed, last-minute features, which is one of the fastest ways to take on debt nobody decided to take on. The fix is the same discipline either way: take debt on purpose, track it, and clear it through steady refactoring rather than one terrifying rewrite. When we hand a project off, the runbook and docs exist partly so the debt you do carry is visible, not a surprise the next team inherits.