The Technical Debt You Should Keep in Your MVP (And the Kind That Kills)

We inherit MVPs from cheaper agencies and founder first builds. Week one is sorting the codebase: debt to keep, debt to pay down, debt to kill before the next investor update. The third bucket is usually the smallest and the most expensive to ignore.

The founder who wrote "If you have zero technical debt, you are probably moving too slow" was right. But the framing has been mangled by enough engineering blogs that founders now default to two equally wrong positions: either "technical debt is fine because we're early" or "we need to refactor everything before we can move forward." Neither survives contact with a post-Series-A codebase.

We call the first bucket Keep-Forever Debt — shortcuts that are cheaper in every state of the world than the thing they're substituting for. The trick is recognizing them under pressure, because they look identical to the kind of debt that kills companies. Both patterns show up as "we didn't build that yet." Only one is safe to leave alone.

The Framework Most Founders Already Use Wrong

Ward Cunningham's original technical debt metaphor, formalized by Martin Fowler, splits debt along two axes: intentional vs inadvertent, and prudent vs reckless. That gives four quadrants:

| | Prudent | Reckless | |---|---|---| | Deliberate | Shipping without full test coverage to validate PMF | "We'll fix it later" with no plan | | Inadvertent | A dev ships duplicate logic unaware; team refactors on review | Compounding problems nobody tracks |

MVPs live in the left column. They die in the bottom-right. The problem is that the left column and the right column look identical from the product side — the user doesn't notice whether the auth check is missing on purpose or by accident. The engineer does. So the question "what technical debt should we keep?" reduces to "which shortcuts are deliberate and prudent, and which are accidental and reckless dressed up in the same clothes?"

Keep: Five Shortcuts That Survive the Full Lifecycle

1. Manual operations for the first 100 customers. Sending welcome emails by hand. Approving signups individually. Wiring up integrations with a human in the loop. The agency playbook says "automate on day one." The Pragmatic Coders piece gets this right: manual processes give you direct feedback loops that automation obscures. Keep them until the manual work costs more than the automation.

2. Hardcoded content before a CMS. Homepage copy in a React component. Pricing page in static markdown. FAQ in a typed array. Non-technical founders want a CMS on day one because their last job had one. They don't need one at 50 users. A Git commit is a perfectly good CMS for a three-person team editing the homepage twice a month.

3. Monolithic architecture until the team is over 10 engineers. Everyone on Hacker News wants to talk about microservices. At MVP scale, microservices add operational cost (service mesh, API contracts, deployment coordination) with zero business benefit. Sam Newman's Building Microservices, 2nd Edition — the canonical reference — is explicit that microservices are a solution to organizational scaling, not application scaling. Don't take on microservices debt to solve a monolith problem you don't have.

4. Feature flags as a "just in case." A $0/month library you never use is cheaper than needing one at the moment you don't have it. Install GrowthBook or PostHog flags during the build, wire up the SDK, and leave it dormant. When you need to dark-launch a feature, the plumbing is already there.

5. A single region for the first 500 paying users. Multi-region costs real engineering time and running cost. Under 500 customers or 10,000 concurrent users, the uptime benefit is dominated by human-error outages a single region handles just as well. Ship single-region. Measure traffic. Add regions when the math demands it.

Kill: Five Shortcuts That Compound

1. No input validation. This is the debt that killed Lovable apps. Veracode found 45% of AI-generated code fails OWASP Top 10 tests; almost all of the gap is validation. Every route that accepts user input needs a schema (Zod, Yup, Pydantic) before it writes anything to the database. This is not debt to defer — it is the structural layer that defines whether the app survives contact with a bot.

2. Auth logic in the UI instead of middleware. "We'll add the middleware later" is the phrase that ships with an open admin API. Frontend auth is decoration; middleware auth is the wall. Every API route needs an auth check running before the handler executes. Missing middleware is the same quadrant as "we'll fix the locks on the bank vault later."

3. No error handling on external API calls. The LLM call that assumed a 200 response. Or the payment webhook where Stripe always succeeds — until the one time it doesn't. The code path hasn't been tested, and it usually corrupts state. Every external call needs a try/catch, a timeout, and a retry policy (or an explicit decision not to retry). This isn't optional production engineering — it's the difference between an app that degrades and an app that crashes.

4. Shared credentials. admin@company.com with a password on a sticky note that three engineers and the founder all use. Or a single AWS key in the team Slack channel. This isn't deferred work — it's a security pattern that gets exponentially harder to untangle as the team grows. Individual credentials from day one, even if it's one person on the team.

5. Data model that assumes single-tenant when you're building multi-tenant. The hardest debt to pay down is the missing org_id column. Adding multi-tenancy to a schema that was designed single-tenant means rewriting every query, every index, and every authorization rule. If the product will have teams, workspaces, or enterprise customers in the first 12 months, build the tenancy column in on day one even if you only need it a year later.

The 20% Rule Almost Works

The standard advice is to spend 10–20% of every sprint on debt repayment. Manager.dev argues this doesn't work in practice, and when we audit inherited codebases the pattern holds: teams who had a 20% rule had spent it on lint rules and dependency upgrades while multi-tenancy debt and unhandled error paths compounded silently. The 20% rule breaks because debt repayment isn't a time-allocation problem. It's a prioritization problem. The fixed budget gets spent on whatever feels most frustrating that week, which is rarely what's actually compounding.

A better rule: pay down debt when velocity drops or regression bugs increase. Track pull request throughput and bug-fix ratio as leading indicators. When either metric trends wrong for two sprints, pause feature work until the underlying cause is fixed. This turns debt repayment into a measurable response to a measurable signal instead of a scheduled tax nobody wants to pay.

Deloitte's 2026 Global Technology Leadership Study puts technical debt at 21–40% of total IT spend in established companies. The MVP stage is where that number is set. Teams that tolerate structural debt early pay it for years; teams that stay clean on the five items in the Kill list above keep that percentage closer to 10%.

What the Framework Won't Tell You

There's one case the quadrant framework doesn't handle cleanly: debt taken on because the founder doesn't know it's debt. An agency delivered the MVP. The founder accepted the handoff. Neither has the context to flag that hardcoded secrets or missing rate limits are in there. This is Fowler's "inadvertent + reckless" quadrant from the founder's perspective, even though it's often "deliberate + reckless" from the agency's. Our honest answer is that you can't manage debt you don't know exists — which is why the first step in any MVP cleanup is an audit, and why the audit costs less than rebuilding from what you find.

What Separates the Buckets

Keep-Forever Debt has one property in common across all five examples: it trades speed now for cost later, where the cost later is bounded and predictable. Manual operations cost more as the customer count grows; the founder knows exactly when to automate. Single-region infrastructure costs more as traffic scales; the load test tells you when to add regions.

Kill debt has the opposite property: unpredictable cost that grows discontinuously. Missing input validation costs nothing until a bot finds an injection vector, then it costs the entire database. No error handling costs nothing until one external API has a bad day, then it costs a data corruption incident. The debt stays silent until it fires all at once.

Monotonic cost curves are debt you manage. Step functions are debt that fires.

Frequently Asked Questions

How much technical debt is normal for an MVP?

There's no target number — what matters is the type. An MVP with extensive Keep-Forever debt (manual operations, monolithic architecture, hardcoded content) is healthy. An MVP with any Kill debt (missing input validation, no middleware auth, shared credentials) is a compounding liability regardless of volume. Debt type predicts survival; debt quantity does not.

When should I start paying down MVP technical debt?

When two measurable signals appear together: pull request throughput drops for two consecutive sprints, and the bug-fix-to-feature ratio exceeds 30%. Time-based rules ("dedicate 20% of every sprint") tend to turn debt work into low-priority chores. Symptom-triggered repayment aligns the effort with the cost it's preventing.

What's the difference between good technical debt and bad technical debt?

Good debt (what Martin Fowler calls "deliberate and prudent") is a conscious shortcut with a known exit strategy — shipping without full test coverage while planning tests in sprint 4. Bad debt is either reckless (knowingly shipping broken code) or inadvertent (shipping problems nobody sees). The two useful questions: is this shortcut tracked somewhere we'll see it again, and does the cost curve grow predictably or explode?

Should I rewrite my MVP or fix the debt incrementally?

Full rewrites routinely introduce new bugs while the old ones linger — Joel Spolsky's Things You Should Never Do, Part I documented this pattern in 2000, and the failure mode hasn't changed. Incremental repayment — migration strategy, strangler fig pattern, feature-by-feature replacement — is the default. Full rewrites only make sense when the existing architecture cannot support the product's next six months, which is a rare condition at MVP stage.

Which technical debt gets flagged in Series A due diligence?

All five items on the Kill list trigger diligence flags: missing input validation (OWASP scan finding), auth in the UI only (pentest finding), unhandled external calls (reliability audit finding), shared credentials (access audit finding), and single-tenant schema for multi-tenant product (architecture interview finding). Debt from the Keep list — manual operations, monolithic architecture, hardcoded content — is invisible to diligence reviewers.

Need help? Talk to an engineer.