Scrolls
5 min read
On this page

When Debt Is the Right Call

There is a phase in every startup's life where code quality is the wrong priority. Before product-market fit, your job is to learn as fast as possible whether anyone wants what you are building. The code is a vehicle for that learning. Optimizing the vehicle instead of the destination is how startups die with beautiful codebases and zero users.

This does not mean quality never matters. It means the right time to care about quality changes based on where you are. The code that gets you your first 100 users is not the code that serves 10,000. And that is fine.

The Two Phases

Phase 1: Before Product-Market Fit
  Goal: Learn what to build
  Optimize for: Speed of iteration, speed of learning
  Acceptable debt: Almost anything that ships faster
  Timeline: Weeks, not months

Phase 2: After Product-Market Fit
  Goal: Build what scales
  Optimize for: Reliability, maintainability, team velocity
  Acceptable debt: Only deliberate, documented, contained
  Timeline: Months, then years

The hard part is recognizing which phase you are in. Most founders think they have PMF before they do. Most engineers want to be in Phase 2 before the business is ready.

Before Product-Market Fit: Take On Debt Aggressively

Before PMF, you are running experiments. Each feature you build is a hypothesis: "If we build X, users will do Y." Most of these hypotheses will be wrong. Building them to production quality is like writing a PhD thesis for a theory you have not tested yet.

What Aggressive Debt Looks Like

Acceptable shortcuts pre-PMF:
  - Single-file scripts instead of proper service architecture
  - SQLite or JSON files instead of a production database
  - Manual processes instead of automation
  - Hardcoded values instead of configuration systems
  - No tests for experimental features
  - Copy-paste instead of abstraction
  - One deploy target instead of multi-environment setup
  - Email alerts instead of proper monitoring

Dropbox's MVP was a video. They did not build the product at all — they tested whether people wanted it. That is the extreme end of the spectrum, but the principle applies to code too. Build the minimum amount of software necessary to test the hypothesis.

Airbnb's early engineering was held together with duct tape. The founders were designers, not engineers. Their first version was a Rails app that could barely handle concurrent users. But it was enough to prove that strangers would pay to sleep in other strangers' homes. That insight was worth more than any amount of clean architecture.

The Learning Loop

Build hypothesis (fast, messy) → Ship → Measure → Learn → Decide:
  → Hypothesis wrong? Throw the code away. No regrets.
  → Hypothesis right? Now invest in building it properly.
  → Unclear? Run another experiment.

Every day you spend making experimental code "clean" is a day you did not spend testing another hypothesis. At pre-PMF stage, the number of hypotheses you can test per month is your most important metric.

What You Should Not Skip Even Pre-PMF

Some shortcuts are not debt — they are landmines:

Never skip, even pre-PMF:
  - Basic security (password hashing, HTTPS, SQL injection prevention)
  - Data backups (you can lose code, you cannot lose user data)
  - Source control (git, obviously)
  - Basic error logging (you need to know when things break)
  - One-command deploy (does not need to be fancy, needs to be repeatable)

These are not quality investments. They are survival basics. Skipping them does not save time — it creates existential risk.

The Transition Point

Product-market fit is not a binary switch. It is a gradient. But there are signals:

Signs you are approaching PMF:
  - Organic growth without paid acquisition
  - Users complain when the product is down (they care)
  - Retention curves flatten instead of dropping to zero
  - You are turning away features to focus on what works
  - Revenue is growing month over month without heroic effort

Signs you are NOT at PMF:
  - You are still pivoting the core value proposition
  - Most users try it once and never come back
  - Growth requires constant manual effort
  - You are building features hoping one of them "sticks"

Superhuman famously created a PMF measurement: survey users and ask "How would you feel if you could no longer use this product?" If 40%+ say "very disappointed," you have PMF. Sean Ellis popularized this threshold, and it has become a widely used benchmark.

After Product-Market Fit: Start Paying Down

Once you know what you are building and who you are building it for, the calculus flips. Now every shortcut slows you down instead of speeding you up.

The compounding problem:
  Month 1: Shortcut saves 3 days
  Month 3: Working around the shortcut costs 1 day/week
  Month 6: The shortcut is now the reason features take 2x longer
  Month 12: New engineers spend their first month learning workarounds

Twitter's fail whale era was a consequence of pre-PMF code carrying a post-PMF load. The Rails monolith that worked for a small user base could not handle the explosive growth. They eventually rewrote core systems in Scala, but the transition was painful and public.

The Post-PMF Investment Checklist

Priority 1 (immediately after PMF confirmation):
  - Automated testing for core user flows
  - CI/CD pipeline that catches regressions
  - Monitoring and alerting for production issues
  - Database migrations to a production-grade setup

Priority 2 (within 3 months):
  - API contracts and documentation
  - Load testing for current and 10x traffic
  - Security audit of authentication and authorization
  - Error handling that does not expose internals to users

Priority 3 (within 6 months):
  - Service boundaries for independently deployable components
  - Automated scaling for traffic spikes
  - Comprehensive logging and observability
  - Onboarding documentation for new engineers

The Rewrite Question

At some point, someone will suggest rewriting everything from scratch. This is almost always wrong.

The rewrite trap:
  "The code is terrible. Let's rewrite it."
  → 6 months of rewriting instead of shipping features
  → The rewrite introduces new bugs while fixing old ones
  → Users do not care that the code is cleaner
  → Competitors ship features while you rewrite

The better approach:
  Strangler fig pattern — replace components incrementally
  → Identify the highest-pain module
  → Build a replacement alongside the old version
  → Migrate traffic gradually
  → Remove the old version
  → Repeat

Netscape's decision to rewrite their browser from scratch is the canonical cautionary tale. It took three years, during which Internet Explorer ate their market share. Joel Spolsky wrote about this in 2000, and the lesson has not changed.

The exception: if the codebase is small enough that a rewrite takes less than two weeks, just do it. The strangler fig pattern is for systems that are too large to replace at once.

Real-World Debt Timelines

Figma:
  Pre-PMF: C++ renderer with minimal architecture. Ship fast, test
  with designers.
  Post-PMF: Invested heavily in performance, multiplayer architecture,
  and plugin system. Did not rewrite — evolved.

Linear:
  Pre-PMF: Focused on speed and feel. Minimal backend complexity.
  Post-PMF: Built sync engine, offline support, real-time
  collaboration. Architectural investment driven by proven user needs.

Notion:
  Pre-PMF: Multiple pivots. Each pivot involved throwing away code.
  Post-PMF: Invested in block-based architecture that could support
  the flexible content model users demanded.

In every case, the pre-PMF code was not the final product. And in every case, that was the right call.

Common Pitfalls

  • Premature optimization disguised as "doing it right." Building a microservice architecture for an app with 10 users is not engineering excellence. It is procrastination.
  • Never transitioning out of Phase 1. Some teams keep writing throwaway code long after they have PMF, because the habit is comfortable. The cost compounds silently until it explodes.
  • Rewriting instead of evolving. The siren call of "let's just start fresh" destroys more startups than bad code does. Incremental improvement is almost always the right path.
  • Confusing PMF with initial traction. A spike in signups after a Product Hunt launch is not PMF. PMF is sustained organic growth with strong retention. Do not invest in scalability based on a press cycle.
  • Letting engineers dictate the transition timing. Engineers will always want to "do it right." That instinct is valuable after PMF and destructive before it. The decision to transition is a business decision informed by engineering, not an engineering decision alone.

Key Takeaways

  • Before product-market fit, optimize for learning speed. Take on debt aggressively. Most of the code you write will be thrown away, and that is the plan.
  • After product-market fit, the same shortcuts that accelerated you will begin to slow you down. Transition to investing in reliability, testing, and maintainability.
  • Never skip security basics, backups, source control, or basic error logging, regardless of stage. These are not quality investments — they are survival requirements.
  • Avoid full rewrites. Use the strangler fig pattern to incrementally replace the worst components while continuing to ship features.
  • The code that gets your first 100 users is not the code that serves 10,000. Accepting this from the start lets you make better decisions at every stage.