Technical debt in founder terms: when to pay it, when to ignore it

Technical debt is what you get when your team takes a shortcut to ship something faster. Not a bug, not sloppiness — a deliberate trade: speed now, extra work later. Every startup that has ever found product-market fit did this on purpose, repeatedly, and was right to. The metaphor is almost literal: your team borrows time and pays it back later with interest, in the form of every future change to that part of the system being harder than it should be.

The problem is that two very different things share the same name. There is debt you chose — a hardcoded pricing table because you don't know your pricing yet, one database doing four jobs because you have eleven customers. And there is debt you accumulated — nobody wrote a test, nobody wrote it down, three people built the same thing three ways and then left. The first is a loan you can repay when the time is right. The second is structural damage, and it gets worse whether or not you touch it.

Here is the number that matters: developers spend somewhere between a quarter and a third of every week servicing this stuff. That is not a moral failing, it is the interest payment. It comes out of your runway whether or not it appears on your roadmap. Your only real choice is whether you are the one deciding how much gets paid, or whether your codebase decides for you.

At pre-seed, clean code is a luxury purchase

Before you have product-market fit, the most expensive thing you can buy is a beautifully engineered version of a product nobody wants. Your scarcest resource is not code quality, it is learning cycles: how many times you can put something in front of a real customer, watch what they do, and change your mind before the money runs out. Shortcuts that let you test an assumption two months earlier are not sloppiness — they are the cheapest research you will ever run.

A clean, well-tested, properly abstracted system is an asset when you know what you are building. Before then it is a bet on the current plan being right, and abstractions built for an unvalidated product tend to abstract the wrong things. The rule: debt taken to learn something is an investment; debt taken because nobody could be bothered is just cost.

Debt announces itself before it bankrupts you

At some point the arithmetic flips and you are paying more in interest than you are getting in borrowed speed. You do not need to read code to spot it. Watch for four things. Estimates that keep growing for work that is not getting harder — if "add a field to the signup form" was two days last year and is two weeks now, and the form has not changed, the system has. Every fix breaking something unrelated, which is what engineers mean by "fragile", and which shows up as a team that has become visibly nervous about deploying.

A new engineer taking months rather than weeks to ship anything meaningful. And the team quietly routing around a part of the system nobody wants to touch — listen for "we don't really touch that" or "only Sam understands billing". That is a no-go zone forming, and no-go zones expand. Any one of these on its own is normal. Three at once means you no longer have a code problem; you have a business problem with a code cause.

Of the four, onboarding time is the one to actually measure, because it needs no engineering knowledge to read. In a healthy codebase at startup size, a new hire's first meaningful change reaches production within days to a couple of weeks. If it routinely takes two or three months, the knowledge required to work safely lives in people's heads rather than in the system — which also means every departure is a small catastrophe.

You're already paying. Decide the number yourself.

Most founders handle debt one of two ways, and both are wrong. The first is to ignore it until it becomes a crisis, then authorise a panicked three-month stabilisation project that delivers nothing customers can see. The second is to declare that everything will now be done properly, which lasts until the first deadline.

The approach that works is boring: a fixed, permanent percentage of engineering capacity, applied to every sprint. Pick a number — 15% is a reasonable default, 20% if the signals above are flashing — and never let a launch borrow against it. It survives because nobody cancels a 15% allocation; it never looks like the reason a deadline slipped, whereas a three-month rewrite always does. And it compounds: the property that makes debt dangerous works in your favour once you pay it down consistently.

Above all, you are paying it anyway: McKinsey's survey of CIOs found 10–20% of the budget nominally allocated to new products gets absorbed by tech debt regardless. Budgeting it means you choose where it goes; not budgeting it means the codebase chooses, usually at the worst possible moment. One refinement — spend the allocation where you work most, not where the code is worst. The ugly corner nobody has touched in two years is a debt with a zero interest rate.

"We need to start again" is almost never the answer

Joel Spolsky called rewriting from scratch "the single worst strategic mistake that any software company can make" in 2000, and the argument holds up because it is not really about code. The ugly parts of an old system encode hard-won knowledge — the edge case for that one enterprise customer, the workaround for a payment provider's bug. That knowledge is invisible in the code and disappears in a rewrite; you will rediscover all of it, in production, in front of customers. And while you rewrite, you stop improving the product your customers actually use. Netscape's three-year gap between releases is still the textbook case, and a startup rarely has three years.

The deeper point is that a rewrite proposal is usually evidence of debt mismanagement rather than a plan for debt paydown. If a system has decayed until incremental improvement feels impossible, the failure was the years of allocating no paydown capacity at all — and starting again without changing that habit produces a new system that reaches the same state faster, because now you are maintaining two. Legitimate rewrites exist, and the good ones run old and new side by side, migrating piece by piece, rather than switching over on one terrifying day.

The playbook

1. 1
   Split the list into "chose" and "accumulated".

   Ask your team for the ten things that slow them down most, then sort each into a deliberate trade-off or something that just happened. Deliberate debt gets a review date. Accumulated debt gets scheduled or explicitly accepted.

2. 2
   Set a standing paydown percentage this week.

   Pick a number between 10% and 20% of engineering time, apply it every sprint, and never let a launch borrow against it. A permanent small allocation beats an occasional heroic sprint by a wide margin.

3. 3
   Measure onboarding time, not code quality.

   You can't read the codebase, so measure the thing you can: days from a new engineer's start date to their first shipped change. If that number is climbing, your debt is compounding — no technical judgement required.

4. 4
   Ask the debt question without inviting a rewrite pitch.

   Say: "If you had four days a month, forever, to make the system easier to work in — what would you spend them on, in order?" It surfaces the real pain, forces prioritisation, and rules out "rebuild everything" by construction.

5. 5
   Tie every paydown item to a business outcome.

   "Refactor the payments module" is unfundable. "Cut the time to launch a new pricing plan from three weeks to three days" is a decision you can make. If your team can't make that translation, that's useful information about the request.

Debt isn't the enemy — unrecorded debt is. The shortcut you chose is an asset right up until the day you forget you took it. The whole discipline is keeping the list.