Technical Debt vs. New Features: How Founders Should Decide

Your lead developer asks for two weeks to work on something no customer will ever see.

He tries to explain it and it doesn’t quite land. Something about the payment code being tangled, about how every change in that area takes three times longer than it should. You have a launch in six weeks and a list of features customers keep emailing you about, and now you’re supposed to decide whether two weeks of runway goes to invisible work. Say no and you might be the founder who wrecked his own product. Say yes and you might be buying somebody’s opinion about how code should look.

I’ve been on both sides of that conversation. I’ve asked for the two weeks, and I’ve been the one telling a team no. The founders who get this right didn’t learn to read code. They stopped treating “technical debt” as one thing.

It isn’t one thing. When your team uses that phrase they mean one of four unrelated situations, and only two of them should ever interrupt your roadmap. You can sort them yourself with a single question: what can’t we do until this is fixed? The rest of this is how to tell which situation you’re actually in.

Why this got harder in the last two years

Two things changed, and they pull in opposite directions.

The first is that a large category of cleanup got much cheaper. Missing tests, inconsistent patterns across files, dependencies three versions behind, undocumented code nobody remembers writing. That work used to be tedious enough that developers avoided it and founders never funded it, because “two weeks writing tests for code that already works” is a hard sell. Claude Code and Copilot do exactly that kind of mechanical work well. On a codebase I picked up last year, adding meaningful test coverage to the billing module took an afternoon. Two years ago that’s a two-week ticket you’d have to argue for.

The second change is less pleasant. When the structure underneath is wrong, AI tools spread the wrongness faster than a human ever could. If your data model treats a company and a user as the same thing, every AI-generated feature inherits that confusion, confidently, in a dozen files at once. A mistake like that used to take six months to work its way through a codebase, and now it happens inside a sprint.

So the sorting matters more than it used to, and it cuts differently. Say yes faster to the mechanical stuff, because it’s nearly free now and the excuse for skipping it is gone. Be more careful than ever about structural problems, because you have less time before they’re everywhere.

The four kinds of technical debt

Debt that’s costing you every week

This is the real thing, and you can spot it without reading a line of code.

Estimates in one area of the product keep inflating. A change that sounds identical to something the team shipped last quarter now takes twice as long. The same feature area breaks repeatedly, and each fix seems to break something adjacent. And somebody on your team says “we have to be careful with that part” often enough that you’ve started to hear it as normal.

That last phrase is the tell. When a section of your product becomes a place your team approaches slowly, it is already costing you, every sprint, in the one thing a small company has going for it: how fast you can respond when a customer asks for something.

I spent ten years on a 400,000-line desktop application. There was a module everyone tiptoed around. Nobody could tell you exactly why anymore, because the person who wrote it had left years earlier and the caution had been handed down like folklore. A two-day feature in that module was a two-week feature, and we’d all quietly built that into our estimates and stopped noticing. The company was paying for a rewrite in installments and had never approved one.

If your developer’s two-week request is aimed at an area like this, the honest math usually favors saying yes. The two weeks are visible and the alternative isn’t, which is the only reason the two weeks feel expensive. You’ve been spending that time already, a day or two at a stretch, on every feature that touches that code.

Debt that’s a loaded gun

Nothing in this category slows your team down today, which is exactly why it never gets fixed.

Customer data that isn’t properly separated between accounts. Passwords and API keys sitting in a configuration file that got checked into your repository. Nobody has ever tested whether the database can actually be restored. One outside service that, if it goes down, takes your whole product with it. A dependency three years old with a published security hole that nobody has gotten around to patching.

None of this shows up in a sprint. It shows up on a Tuesday when a customer sees another customer’s data, and by that point the engineering is the least of your problems. The question that matters is whether the person who found it tweets first or emails you first.

I applied Always Encrypted to user profile data on a product that wasn’t in any regulated industry and had no legal requirement to do it. Some people thought that was overkill for a startup. It cost about a day. My reasoning was that the founder was going to be asked “how do you protect our data?” by exactly the kind of enterprise customer he wanted, and I’d rather he answer that question with a fact than a promise.

This bucket is not a prioritization conversation. If your team raises something in it, it goes to the top, and the only negotiation is about the smallest version that closes the exposure.

Debt that only matters if something specific happens

Most of the money founders waste on engineering gets spent in this bucket, early, on problems they don’t have yet.

Your team wants to rearchitect for a scale you haven’t reached. Split into microservices before you have enough engineers for it to help. Build multi-region support before you have a single customer outside your country. Add a caching layer for traffic that’s currently running about forty requests a minute.

The honest answer is almost always: not yet, and write down what would change that.

I chose a modular monolith over microservices for an AI SaaS product two years ago and it was the right call by a wide margin. Microservices solve a real problem, but it’s a coordination problem, the kind that shows up when a lot of engineers are stepping on each other in the same codebase. This team was two people. A two-person team doesn’t have a coordination problem; what it has is a runway problem, and the modular part of a modular monolith means the seams are already drawn if the day comes when splitting makes sense.

That’s the posture for this whole bucket. Refusing the work outright is a mistake; so is doing it now. What you want is to keep the option open at a reasonable price, which in practice means keeping the seams clean and skipping the machinery until something forces the issue.

One exception worth naming, because it’s the one that has bitten founders I’ve worked with: multi-tenancy. Whether your system can cleanly serve multiple customers with separated data is close to impossible to retrofit and cheap to design in from the start. I’ve built it in on day one for products with a single customer, and every time the business later expanded into a new vertical, that decision paid for itself several times over. Ask your team where their line is between “deferrable” and “one-way door.” A good developer has a clear answer.

Debt that’s really a preference

Some requests are about taste. The framework is old-fashioned. The code isn’t as clean as your developer would like. There’s a newer approach they’ve been reading about.

I want to be careful here, because engineers get accused of this unfairly all the time, and taste is not a character flaw. Sometimes “this code is ugly” is a trained instinct pointing at a real problem the person hasn’t articulated yet. So don’t dismiss it. Test it with the same question you’d ask about anything else, and see whether an answer comes back that’s about your business.

If the answer is “we’d be able to ship changes in that area much faster,” it moved buckets. If the answer stays at the level of what’s modern or what the developer prefers working in, it’s a preference, and preferences go on a list for a slow week. React, for what it’s worth, is my own least favorite framework, and I’ve still shipped products on it because that’s what the team knew and the business didn’t care.

The questions that get you a real answer

You don’t need to evaluate the technical claim. You need to make the person explain the business consequence, and there are four questions that reliably do it.

“What can’t we do until this is fixed?” If the answer names something concrete on your roadmap, it’s real. If the answer is abstract, you’ve learned something.

“What is this costing us right now, in developer time?” A good developer will estimate it. Two extra days a month is twenty-four days a year, so a ten-day fix pays for itself around month five and everything after that is yours. If nobody can put a number on it at all, that tells you something too.

“If we wait six months, is this harder or the same?” Some problems sit still. Structural problems compound, because every feature you build on top of a bad foundation is another thing that has to be untangled later. Ask directly whether this one grows.

“What’s the smallest version that gets us most of the benefit?” This is the most useful question in the set. A two-week ask is frequently a three-day fix with a wish list stapled to it. Ask it as a real question rather than a haggle, because what you’re after is where the value actually sits in the request. I’ve had my own estimates cut down by this question and been right to have them cut.

Three signals you can watch without reading code

Ask your team for these once a month. All three are things a founder can act on.

How long from decision to customers using it. Pick a feature, mark the day you decided to build it, mark the day a customer used it. That number is the health of your delivery flow, and it’s the one I’d keep if I could keep only one. In one organization I worked with, that number went from two months to a single day, and nothing about that project was glamorous. It was mostly removing steps that existed because they’d always existed.

How often a release causes a problem. Not bugs found, but deployments that had to be rolled back or hotfixed. If one in three releases causes drama, your team isn’t careless. They’re missing guardrails, usually automated tests and a way to turn features off without a deployment.

Where the careful zone is. Ask your developers which parts of the product they slow down for. They know. They’ll tell you in ten seconds if you ask plainly and it’s clear you’re not looking for someone to blame. That map is your debt list, and it’s more accurate than anything a tool will generate for you.

Fund it continuously, not in sprints

The most common structure I see is the debt sprint: two weeks, once a quarter, dedicated to cleanup. It sounds disciplined. It rarely survives contact with a real quarter, because when a customer escalation lands in week eleven, the cleanup sprint is the first thing cancelled. It gets cancelled twice, and now your team has stopped believing it exists.

What works better is a standing slice of every cycle, somewhere between ten and twenty percent, spent in the area the team is already building in. Your developer is in the billing code this week for a feature anyway. The context is loaded. Fixing the tangle there costs a fraction of what it costs as a standalone project three months from now.

This also removes the ceremony. Nobody has to write a proposal or win an argument to clean up code they’re already touching. That’s how it becomes muscle memory instead of a negotiation you have four times a year.

The exception is anything in the loaded-gun bucket. That doesn’t wait for the slice. It goes now.

Anti-patterns to avoid

Saying yes because you feel guilty. Founders who’ve been told they moved too fast sometimes overcorrect and approve everything an engineer labels debt. Guilt is not a prioritization framework, and your team knows the difference.

Deferring without a trigger. “Not yet” is a fine answer that becomes a bad one when nobody writes down what would change it. Every deferral needs a condition: we revisit when we sign a customer over 500 seats, when we take a second market, when the same problem costs us a week. Write it in one sentence next to the item. Without the trigger, “later” quietly becomes “never” and the decision gets made by whoever gets frustrated first.

Cleaning up code you’re about to replace. I’ve watched a team spend a sprint refactoring a module that got deleted eleven weeks later during a redesign nobody had mentioned. Before approving any cleanup, ask whether that part of the product is likely to survive the next two quarters.

Treating the loudest engineer as the most accurate one. The person who complains most about the codebase isn’t necessarily the person who understands where the risk is. Ask the quieter developers what worries them. You’ll usually hear something different, and the gap between the two lists is worth your attention.

How to start, gently

You don’t need a process. Do these four things over the next month.

The next time someone asks for time on invisible work, ask what can’t we do until this is fixed, and then stay quiet long enough for a real answer. Most of the sorting happens right there.

Then start a one-page list, four sections, matching the four buckets above. Sit with your lead developer for thirty minutes and fill it in together. That half hour is the highest-value technical conversation most founders have all quarter, and both of you will learn something. Update it monthly.

Pick one signal and track it. I’d start with how long it takes from deciding to build something to a customer using it, because it’s the one that improves for every reason you care about.

Then take the smallest item in the loaded-gun section and fix it this week. Not the biggest one. The smallest. Getting one thing off that list changes how the whole list feels, and it proves to your team that raising this kind of thing with you leads somewhere.

And the next time your developer asks for two weeks, the conversation will go differently, because he’ll know you keep a list and ask real questions. The requests get more honest in both directions.

When was the last time your team asked for time on work no customer would see, and how did you actually decide? I’d bet the thing that tipped it wasn’t the technical explanation.