Technical debt: the non-technical founder’s guide (4 types, diagnostic)

On a Wednesday in November, in an office in São Paulo, the founder of a Series A fintech heard the same sentence for the third time that month: “we need to stop building features for six weeks and pay down the technical debt.” It was the first time he understood that this was his problem, not his tech lead’s. The investors were asking for a product plan for the next twelve months. The engineering team was asking for six weeks of stop work. The two requests collided, and the decision was his.

That’s the exact moment most non-technical founders discover what technical debt is. Too late to avoid it. Too early to understand what’s being proposed.

What technical debt is, in a founder’s language

Technical debt is any engineering choice that trades future quality for speed today. You write the code faster now, knowing you’ll pay the difference later: in maintenance, in bugs, in refactor work, or in a new engineer who takes three weeks to figure out what’s happening.

Ward Cunningham coined the term in the 1990s, and the metaphor is exact. Like financial debt, technical debt accrues interest. Every release built on top of a shaky foundation adds a little more friction, a little more time, a little more risk. If you never pay, the interest eats your team’s velocity. If you always pay, you’re leaving velocity on the table that could have been invested in product.

What matters for the founder is not the academic definition. It’s understanding that technical debt is never a surprise the team created. It’s the byproduct of decisions that were made, explicitly or implicitly, so you could ship the investor demo, close the first customer, or launch the pilot before a competitor. The debt didn’t appear out of incompetence. It appeared because someone prioritized speed. Probably you.

Why this becomes your problem, not the CTO’s

Three things change when technical debt stops being an engineering conversation and starts being a company conversation.

The first is release pace. Teams with heavy debt start to feel every feature get slower. What used to ship in two weeks now ships in four. Not because the engineers got worse. Because more and more of their time is spent dodging traps the old code left.

The second is hiring risk. Heavy-debt teams are hard to scale. When you try to double the squad to move faster, you discover that the new engineer needs six weeks before they can open a pull request without breaking three things. Your onboarding rate collapses. You think hiring is expensive; in reality, ramp-up is expensive.

The third is due diligence risk. In a Series A round or an acquisition, the investor hires a technical due diligence firm. They spend four days inside your repository, talk to the team, and produce a document that says whether the codebase can support the next twenty-four months or not. If the debt is too high, the investor can ask for a discount on valuation. They can ask for “debt paydown” milestones before the next tranche. In rare cases, they can walk.

None of those three effects is technical. All of them are business. And all of them reach the founder sooner or later.

The four types of technical debt that matter

Martin Fowler, one of the writers who has thought about this longest, created a two-axis matrix that separates the four situations in which technical debt appears. For the founder, the matrix is useful because it answers a single, important question: is my team doing this on purpose, or are they doing this by accident? That question separates “strategic” debt (which you may be happy to carry) from “dangerous” debt (which is costing you money silently).

1. Deliberate and prudent: “we know what we’re doing, and we’ll pay later”

The team consciously chose to write simpler, faster code because they needed to get somewhere first. Maybe the TechCrunch demo. Maybe the pilot with a flagship customer. Maybe the pre-holiday release. They documented the choice. They know where the shortcut is. They have a date, even an approximate one, to come back and do it right.

This is the debt you want in the company for the first eighteen months. Without it, you don’t reach PMF in time.

2. Deliberate and reckless: “we know what we’re doing, and we’ll never pay”

The team picked the shortcut, knows it’s a shortcut, and is convinced there’s still time to break three things before release. Often this debt comes from the founder themselves: “I need this by Friday, make it happen.” The team warns it’s a bad idea. You say “we’ll fix it later.” It doesn’t get fixed.

This is the most common and most expensive type. Not because it’s the worst technically, but because the “later” never arrives. And because it accumulates in silence: you don’t see the debt on the balance sheet. You only see the feature shipped.

3. Inadvertent and prudent: “now we know how we should have done it”

The team did the best they knew at the time, with the information they had. They learned more about the problem, the architecture, the users, and today they’d do it differently. It isn’t carelessness. It’s the natural learning curve of any new product.

You’ll always have this debt. The right question for this type isn’t “how do I avoid it?”. It’s “when do I go back and redo it?”. And the honest answer is: when the feature sitting on top of the wrong foundation starts costing more to evolve than to rewrite.

4. Inadvertent and reckless: “we don’t even know this is debt”

The team doesn’t know they chose a bad path. They didn’t document anything. They’ll find out the next time someone needs to touch that piece of the code, and the next person who touches it will suffer without understanding why. This is the most dangerous category because it’s invisible. You only notice when someone quits and the knowledge walks out the door, or when the new senior dev opens the repository and takes a long breath.

The difference between types 2 and 4 is where the founder’s work lives. Type 2 you can trace by talking to the team. Type 4 you need an internal due diligence to find, and almost no founder runs one before the bill arrives.

The four-question diagnostic

You don’t need to fake technical depth to figure out how much debt your product is carrying. You need four questions, twenty minutes with each engineer, and the courage to listen to the answers without getting defensive.

Question 1: “What’s the piece of code nobody wants to touch?”

Every codebase has one. It might be the payments module, the auth system, the commissions engine. What you’re listening for is a proper name. If three engineers name the same thing, that’s the heart of your inadvertent reckless debt.

Question 2: “How many times last sprint did we do a workaround because the right solution would take too long?”

This question detects deliberate debt, the type 2 kind. A healthy answer is “once, and we opened a ticket to come back.” An alarm answer is “three or four, no tickets.” A workaround without a ticket is debt that won’t be paid.

Question 3: “If we wanted to double the team tomorrow, how many weeks until the new engineer opens their first PR?”

Healthy teams answer one to two weeks. High-debt teams answer four to eight. Above that, your debt is no longer a product problem. It’s a team-scaling problem.

Question 4: “If we lost engineer X, which piece of the product would be orphaned?”

This question is the intersection between technical debt and bus factor. Undocumented knowledge is inadvertent reckless debt, and it disappears with the person. If the answer is “half of it,” you have two problems, not one.

The four questions together give you a reasonable map of the state of your codebase. It’s not a formal technical due diligence. But it’s enough for you to decide, with a clear head, whether the team needs six weeks of stop work to pay down debt or whether they’re asking for six weeks to rewrite something that works.

When to pay, when to carry, when to ignore

Not every debt should be paid. That’s the mistake most founders make in the opposite direction: after understanding the concept, they get anxious to “zero out the debt.” That isn’t how it works.

Carry the debt that’s stable. If a piece of code is messy but nobody has needed to touch it in six months, leave it. The rule is simple: debt only costs you if you’re paying interest. Code nobody opens has no interest.

Pay the debt that’s in the path of the roadmap. If next quarter requires changes to module X, and module X is a mess, it’s worth paying down the debt before. You were going to pay for the refactor anyway, embedded in the feature, with no visibility.

Rewrite (not pay) the debt that’s blocking growth. If the auth system can’t handle more than a thousand simultaneous users, or if the calculation engine takes three hours to run with five thousand customers, that isn’t debt. It’s architecture that needs to be replaced. You aren’t paying interest. You’re in a dead end. The conversation there turns into a software rewrite, which is a different and much more expensive decision.

The heuristic we use when working with non-technical founders: look at debt from the roadmap side, not from the code side. What gets touched in the next ninety days, and is hard to touch? That’s what’s worth paying. The rest is cosmetic.

The conversation that has to happen with the team

The wrong conversation starts like this: “can you give me an estimate of how much technical debt we have?” You won’t get a useful answer. Nobody can quantify debt in hours or dollars with precision. The team will guess, you’ll doubt the guess, and the conversation goes nowhere.

The right conversation starts differently. Pull up the roadmap for the next ninety days. For each item, ask: “does this item touch a piece where we have debt worth paying before?”. If the answer is yes for three or four items in the same module, that’s the piece where you want to invest a refactor sprint before continuing.

This conversation works because it ties debt to what’s being built. It isn’t “stop everything and fix the past.” It’s “let’s invest a week now so the next quarter moves faster.” Investors understand that language. Co-founders understand it. You can defend it at the board.

And it has a secondary effect: it forces the team to point at specific debt, not generic debt. “We have debt in the payments module that will weigh on the next three projects” is an actionable sentence. “We have a lot of technical debt” isn’t.

What changes when you outsource development

If you don’t have an in-house team, and your product is being built by a software house or development partner, the dynamics of debt change in two important ways.

The first: inadvertent reckless debt is harder to detect. The external team isn’t on your Slack every day, so the question “what’s the piece of code nobody wants to touch?” needs to be asked more often, and the answer has to come with screenshots, commits, examples. Trust data, not feeling.

The second: deliberate prudent debt is easier to carry, because an experienced partner will tell you, before every release, what’s being deferred and why. Good partners do this by habit. Bad partners ship the product and disappear. The difference between the two shows up in exactly that transparency: do you or don’t you know where the debt is when the release goes out?

The rule we apply when we build software for non-technical founders is simple: every decision to take on deliberate prudent debt has to be recorded in one sentence on the PR, and it has to appear in the monthly status document. If you don’t have that, you’re in the dark. It isn’t that the partner is malicious; it’s that the process is poorly designed.

When technical debt becomes a maintenance cost problem

Your product’s monthly maintenance cost is, in part, the interest payment on the debt you took. If your team spends sixty percent of their time “fixing things” and forty percent “building things,” most of that sixty percent is interest, not bugs.

Healthy teams sit around eighty-twenty (eighty building, twenty fixing). Heavy-debt teams flip it: sixty-forty. Critical teams reach twenty-eighty, and at that point you’re not building product anymore. You’re keeping a skeleton alive while your competitors ship features.

The ratio is one of the easiest things to measure and one of the most underrated. If you don’t know yours, ask the team. They know. They’ve probably known for months.

Frequently asked questions

What is technical debt?
It’s any engineering choice that trades future quality for speed today. Like financial debt, it accrues interest: every release built on a shaky foundation adds a little more time, friction, and risk. It can be deliberate (you chose the shortcut) or inadvertent (the team learned later that they could have done it differently).

What’s the difference between technical debt and tech debt?
None. The two terms are used as synonyms in the industry. “Technical debt” is the original, slightly more formal version; “tech debt” is the everyday shorthand engineers use in standups.

What are the four types of technical debt?
The matrix most often used is Martin Fowler’s, which crosses two axes: deliberate/inadvertent and prudent/reckless. That gives four types: deliberate and prudent (you took the shortcut and will pay it down), deliberate and reckless (you took the shortcut and won’t pay), inadvertent and prudent (you learned later and redo when it’s worth it), inadvertent and reckless (the team doesn’t even know there’s debt there). Types 2 and 4 are the ones that most hurt the non-technical founder.

How long does it take to pay down technical debt?
There’s no single answer. It depends on the size of the codebase, the type of debt, and how much of the future roadmap crosses it. A rule of thumb we use: if a specific area is blocking three or four items in the next ninety days, invest one to two weeks of focused sprint on it before moving on. Attempts to “pay down all the debt” in a single push rarely work: the team loses months and the product backlog freezes.

How do you measure technical debt?
You don’t, with precision. You can proxy it through the four-question diagnostic above, through the build-vs-fix ratio (how much of the team’s time is spent fixing rather than building), and through ramp-up time for a new engineer. None of these are exact, but together they tell you whether your debt is in healthy or dangerous territory.

Most non-technical founders learn the concept of technical debt at the worst possible moment: when the team asks to stop, when the investor asks to accelerate, or when a due diligence flags a problem nobody saw coming. The founder who decides well in that moment isn’t the one who understands more code. It’s the one who reads debt as a business decision and asks the team the right question: what about the next ninety days is harder because we haven’t paid yet?

That founder doesn’t have to be technical. They have to be clear.