The metaphor that runs every engineering conversation in SaaS — and the reason solo founders accumulate it faster than teams ever do.
Research-based overview. Sources include Ward Cunningham's original talks, Martin Fowler's essays, and field notes from solo founders. How we research.
The phrase comes from Ward Cunningham, the inventor of the wiki and one of the original signatories of the Agile Manifesto. He coined it in 1992 in a report he wrote at WyCash, a financial software company, and elaborated on it in a 2009 talk titled “Debt Metaphor,” recorded and still hosted publicly at youtube.com/watch?v=pqeJFYwnkjE.
Cunningham's original framing is more subtle than how the phrase is used today. He did not say “technical debt” meant sloppy code. He said:
“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. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
The key word is not-quite-right. Cunningham's debt was about your understanding of the problem, not the cleanliness of your code. You ship something based on what you currently understand. Later you understand more, and the original code no longer reflects your improved understanding. That gap — between what you know now and what the code expresses — is the debt.
Most modern usage has slid away from this. Today “tech debt” usually means “ugly code I am embarrassed about,” which is closer to what Martin Fowler calls cruft. Worth keeping the distinction.
Martin Fowler later expanded the metaphor into a 2×2 grid (deliberate vs inadvertent, prudent vs reckless). For solo founders, the distinction that matters most is simpler: deliberate-and-strategic vs accidental-and-creeping. They look similar in a code review. They behave very differently over time.
You decide, with full awareness, to take a shortcut because shipping fast is more valuable than shipping right. Examples a solo founder will recognize:
This debt has a known interest rate. You can plan around it. You took it on consciously, which means you can also pay it down consciously when the moment comes.
You did not decide to take this on. It accumulated while you were not looking. Examples:
This is the dangerous kind. You did not budget for it. You are not tracking it. The interest payment is paid every time a future change brushes against it — in the form of bugs, slow comprehension, and confidence loss. Fowler's essay at martinfowler.com/bliki/TechnicalDebtQuadrant.html covers this in more depth.
This is the part that gets under-discussed in the standard tech-debt literature, which is mostly written for and about engineering teams. Solo founders have structural conditions that accelerate debt accumulation in ways teams do not.
No code review. A second pair of eyes catches inconsistencies, bad naming, premature abstractions, and obvious drift. As a solo founder, you are reviewing your own work at midnight on a Wednesday after a 10-hour day. The work that gets shipped is the work that compiles, not the work that has been examined.
No second opinion on architecture. When you are the only person who has held the system in your head, you tend to over-trust your own past judgments. A small bad decision in week three becomes a foundational bad decision in month nine because nobody has had reason to question it.
No team velocity pressure. Teams accumulate debt mostly because of deadlines and feature pressure. Solo founders accumulate debt because their context-switching cost is high and shortcuts are cheaper than investigations. The debt mechanism is different but the result is the same.
AI-assisted code generation amplifies all three. If you are using Cursor, Claude, or Copilot, you can generate plausible-looking code at 10× the rate you can carefully review it. The generation runs ahead of the comprehension. Our piece on how to build a SaaS with Claude covers ways to keep this from spiralling, including reviewing generated code as if a junior engineer wrote it.
Here is the inversion that under-experienced founders miss: debt taken on a feature that ends up unused costs nothing. The interest payment only kicks in when you keep editing the code. If a feature ships, performs poorly, and gets removed three months later, the debt was free. You shipped fast, learned, and threw it away before it ever charged interest.
This is a profoundly important insight at the MVP stage. The right strategy pre-product-market-fit is to take on as much deliberate, isolated, well-fenced debt as possible because most of what you ship will be cut. Compare this to a 50-engineer team building the same feature, where every line of code is expected to live for three years. Solo founders should ship code with much shorter expected lifespan, which means much higher tolerable debt levels.
Three areas of a SaaS codebase punish accumulated debt unforgivingly. If you have a choice about where to be careful, be careful here.
Authentication, session handling, and authorization checks are where bugs become security incidents. Bad auth code does not just slow you down later — it leaks customer data, exposes one tenant's information to another, and ends companies. Use a vendor (Clerk, Auth0, Supabase Auth) instead of writing your own. Treat the auth code that does exist as if it were production-critical from day one.
The shape of your database is the most expensive thing to change later. A schema that conflated two concepts in week two will require a multi-week migration in year two. Spend an extra hour up front to model your core entities cleanly. Once a column is in production with a million rows, the cost of renaming it is two orders of magnitude higher than getting the name right the first time.
The most insidious debt is the kind you cannot see until you try to ship a new feature. You sit down to add team workspaces and discover that your entire database assumes single-user accounts. You sit down to add billing tiers and discover that your subscription logic is hardcoded for one price point. This kind of blocking debt is the right kind to pay down preemptively when you can see the shape of the next quarter's roadmap. The signals for when the rewrite itself is justified are covered in our when to rewrite your SaaS guide.
Most founders default to one of two extremes — either they ignore debt entirely or they declare a “rewrite quarter” that consumes three months and produces no new revenue. Both are mistakes. The pragmatic path is incremental.
When you find yourself reading the same 30 lines of logic in two places, extract the function. Do not refactor everything around it. Just pull out the one helper, name it, and move on. This is how you compound understanding without ever stopping to do a “cleanup pass.”
Bad variable names are the cheapest debt to pay down. Modern editors will do the rename across the codebase in seconds. If a name has drifted from its meaning, rename it the moment you notice. The cost is 30 seconds; the comprehension benefit compounds for the life of the code.
Robert Martin's phrasing: leave the code a little better than you found it. Every time you touch a file for any reason, fix one small thing. Tighten one variable name, delete one dead branch, add one test. You will never have time for a cleanup quarter, but you can always afford to leave one file slightly improved on your way through.
Choosing the right tooling makes this much easier. Our breakdown of the solo founder tech stack emphasizes tools that lower the cost of small refactors — TypeScript, Prettier, ESLint, and the AI-assisted editors covered in our best AI tools for solo SaaS founders roundup.
Technical debt is a tool, not a sin. Used deliberately, in well-fenced places, on code that may not survive long enough to charge interest, debt is one of the most powerful instruments a solo founder has. Used carelessly, in the auth path or the data model or the parts of your roadmap you cannot yet see, it is the thing that quietly ends your runway. The discipline is not to avoid debt. It is to know which kind you have and where it is.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.