What is Technical Debt? A Founder's Guide to the Hidden Tax

If you have ever asked your engineering team why a “small change” took a week, you have run into technical debt. It is the most-cited and least-understood concept in software — invoked to explain everything from a slow sprint to a failed acquisition.

This is a founder’s working definition: what technical debt actually is, what causes it, what it costs you, and the simple decision framework for what to fix versus what to leave alone.

The Original Metaphor

The phrase comes from Ward Cunningham, who used it to explain why the first version of a piece of software is allowed to be imperfect:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… Every minute spent on not-quite-right code counts as interest on that debt.

The metaphor works because, like financial debt, technical debt:

• Can be taken on deliberately in exchange for something valuable (a faster launch, a market window, a learning opportunity).
• Carries interest — every change you make to a debt-laden area is slower than it would be otherwise.
• Can be paid down by deliberate work that produces no visible new feature.
• Compounds if you ignore it long enough.

The metaphor breaks because debt instruments have a defined principal and rate. Technical debt does not. You discover the real cost by trying to change the code, not by reading a statement.

What Causes It

Five sources, in roughly the order founders encounter them:

1. Time pressure

The classic source. A feature ships in two days instead of two weeks because the team takes shortcuts. Hardcoded values instead of configuration. A copy-paste instead of an abstraction. A test skipped because “we’ll add it later.”

Often the right call. A startup that hits a market window with a debt-laden v1 beats a startup that misses it with a clean v2.

2. Changing requirements

The product you built reflects the product you thought you needed. Two years later, the product you need has shifted. The data model that made sense in v1 fights every new feature in v3. The codebase did not fail — the world moved.

This is the largest source of debt at scale. It is also the least the original engineers’ fault.

3. Team turnover

The engineer who designed the auth system left. Two years later, no one quite remembers why the system makes the decisions it makes. Changes are made carefully and slowly, because the cost of breaking something nobody understands is high. Velocity drops without any code being added or removed.

4. Framework and dependency rot

You built on React 17. React is now on version 19. Three of your major dependencies have been deprecated. Your Node.js LTS is end-of-lifed. None of this was a mistake when you made it — the world simply moved on. Catching back up has a cost.

5. Lack of architectural planning

The most expensive kind. The original system was built without thinking through what it would need to do at 10x scale or with 10x the data. The decisions baked into the schema and the service boundaries are now fighting every feature. The fix is rarely surgical — it is structural.

We’ve written about how to avoid this category at the design stage in API-first architecture and SaaS platform architecture decisions.

The Types Founders Should Recognise

Not all debt is the same shape. The taxonomy worth knowing:

Type	What it looks like	Cost signal
Code debt	Messy code that works	Engineers complain when assigned to that area
Architecture debt	Structural decisions that no longer fit	Every new feature is three times harder than it should be
Test debt	Missing or flaky tests	Engineers afraid to refactor; bugs ship to prod
Infrastructure debt	Manual deploys, no monitoring	Outages take hours to diagnose
Documentation debt	Knowledge in one person’s head	New hires take six months to be productive
Dependency debt	Old libraries, known CVEs	Security review keeps flagging the same packages
Data debt	Schema that fights every new question	Analytics requests take weeks

Founders tend to focus on code debt because it is the most visible. The expensive ones are architecture, data, and dependency debt — they are easier to ignore and more painful to fix.

What Technical Debt Actually Costs You

Three costs, in order of severity:

1. Velocity tax (the obvious one)

Engineering ships fewer features per quarter than it used to. A change that took three days a year ago takes a week today. New hires take longer to become productive. The team’s frustration shows up in pull request comments before it shows up in retention.

A rough heuristic: when 30%+ of engineering time goes to debt-related work (paying down, working around, fixing bugs caused by it), you have crossed the line where velocity collapses.

2. Optionality loss (the hidden one)

The most expensive cost. Debt-laden systems make some product moves impossible — not slow, impossible. You cannot ship the enterprise SSO your biggest prospect is asking for because the auth model assumes single-tenant. You cannot expand to the EU because the data model was never built with residency in mind. You cannot refactor pricing because the billing schema is too brittle.

The features you can’t ship don’t show up in any metric. They show up in lost deals.

3. Acquisition and investor risk

Technical due diligence is a real thing. A 200-page DD report that flags architecture debt, dependency CVEs, and missing tests reduces your valuation or kills the round. Acquirers have walked from term sheets because the codebase was, in the diligence team’s words, “structurally not viable to operate.”

We’ve seen this from both sides — running technical due diligence and shipping the post-DD remediation work.

How to Tell If You Have Too Much

Quantitative signals worth tracking:

• Build times. Going up over months is a leading indicator.
• Deploy frequency. Going down is a lagging indicator — by the time deploys stop, the team is already working around fear.
• Mean time to fix a production bug. Trending up is a debt signal.
• % of engineering time on bug-fix / debt vs new feature work. Track it. Above 30% is a problem.
• Dependency age. Run npm outdated or its equivalent. If half your deps are two majors behind, you have dependency debt.
• Open CVEs in dependencies. Above a handful, you have security debt.

Qualitative signal worth trusting more than any of the above:

How long does it take an experienced engineer to ship a small behaviour change in this area of the codebase?

If the answer is “a day,” the area is healthy. If the answer is “three days, because I have to read four files to understand what side effects I might be triggering,” the area has debt. If the answer is “we don’t change that,” the area is bankrupt.

When to Refactor vs Ship Features

The decision framework, in three rules:

Rule 1: Refactor on the path of your next feature

If your next three features all need to touch the same fragile area, refactor it first. The refactor pays for itself in those three features and reduces ongoing interest forever.

If only one feature needs to touch it, work around the debt for now. You can always come back.

Rule 2: Refactor when the workaround is more expensive than the fix

If every new feature requires a 2-day “deal with the auth model” tax, the auth model refactor at 2 weeks is positive ROI after 5 features. Compute the breakeven and the case writes itself.

Rule 3: Refactor when debt blocks revenue or risk

Anything in the path of an enterprise deal, a regulatory requirement, or a P0 outage gets fixed now, not later. Everything else competes for time on its merits.

Things to avoid:

• The Big Rewrite. Almost always wrong. We have a whole post on rebuild vs refactor — refactor wins more often than founders expect.
• Refactoring for cleanliness alone. Code that nobody touches is fine being ugly. Tidy code that nobody will read is a waste.
• Refactoring without a hypothesis. “Make it better” is not a goal. “Reduce the time to ship a feature in module X from 5 days to 2 days” is.

How to Keep Debt Visible

A few small practices that prevent invisible debt from compounding:

• Mark deliberate shortcuts in code. // TODO(debt): hardcoded for v1, needs config service when we ship multi-tenant. Tag them so they can be queried.
• Keep a debt register. A simple list — one row per known debt item, what it blocks, rough cost to fix, rough cost of leaving it. Owned by the tech lead.
• Allocate a fixed % of each sprint to debt paydown. 10–20% is normal. Skip the week and the debt grows; skip it for a quarter and morale tanks.
• Add tech-debt review to your roadmap process. When a new feature is proposed, the question “what debt does this touch?” goes in the brief alongside scope and effort.

The Founder’s Take

Technical debt is not a sign of bad engineering. It is a sign of a team that shipped something. The question is not “do we have debt” — every team does — but “is our debt deliberate, visible and managed?”

If the answer is yes, debt is a tool. You take it on when it buys you speed, pay it down when it threatens to compound, and live with the rest.

If the answer is no, the debt is running you instead. The first sign is usually a founder asking why a small change took a week. The second sign is the team starting to leave.

If you are scoping a build and want it architected for the next three years, not just the next sprint — tell us about the project. We design SaaS platforms specifically to keep architecture debt low through the period when it matters most.