You have paying users. Maybe 200, maybe 2,000. The product was glued together in a weekend with Lovable, Cursor, and three frantic prompts to Claude. Now a senior engineer has looked at the repo, sucked air through their teeth, and told you the only way forward is a full rewrite.
That advice is wrong more often than it's right, and the cost of getting it wrong is brutal. Netscape took the rewrite advice in 1998. By the time Netscape 6.0 shipped in November 2000, Internet Explorer had already overtaken Navigator and Netscape's browser business had lost the market window it needed to defend. Digg v4 did the dangerous version of a rewrite: it replaced the code, architecture, infrastructure, and the community mechanics users depended on. Traffic fell 26% in the month after launch and Reddit's traffic grew 230% the same year. By 2012 Digg was sold to Betaworks.
This post is for the founder or first technical lead staring at a vibe-coded codebase, holding a quote for a $45K rewrite, wondering if there's another way. There is. It's slower in month one and far faster in months three through twelve, and it's the only path that doesn't cost you the customers you already have.
The rewrite fantasy is real, and the math behind it isn't
Before we tear down the rewrite, let's give it its due. The fantasy is seductive for honest reasons. The codebase looks like spaghetti. Every new feature breaks two old ones. You're embarrassed to show the repo to anyone you'd want to hire. The vibe-coding tools made the first version feel free, so the second version should feel free too.
It won't. The numbers are well-known and rarely shown to founders considering a rewrite. McKinsey and the University of Oxford studied more than 5,400 large IT projects with initial budgets over $15M. On average, those projects ran 45% over budget, 7% over time, and delivered 56% less value than predicted, with $66B in total cost overrun across the sample. That does not mean your $45K rebuild has the same risk profile. It means the moment you turn a bounded product problem into a broad replacement project, the base-rate math gets uglier.
For vibe-coded MVPs specifically, a useful planning heuristic is that the rebuild quote often lands around 2-3x the original AI-assisted prototype spend. A $15K weekend MVP becoming a $45K rebuild is not a law. It is the number you should budget against before you accept the "just rebuild it" advice.
Why "just rebuild it" is the default advice (and why it's still wrong)
Joel Spolsky wrote the canonical takedown in April 2000, after Netscape's rewrite was already in motion. His core argument has aged perfectly: it is harder to read code than to write it. When you look at a messy codebase and think "this is a disaster," what you're mostly seeing is your own unfamiliarity with someone else's reasoning. The mess is also load-bearing. It contains every bug fix that took weeks of real-world usage to find: the obscure edge case where Nancy's installer broke because she didn't have Internet Explorer, the auth flow that handles a payment provider's three-second delay, the rate-limit retry that exists because a user's iPad keeps dropping connection on the subway.
Throw away the code and you throw out Nancy. You also throw out three to twelve months of runway during which your competitors keep shipping. Spolsky put it bluntly: "You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years."
There's a less polite reason rewrite advice is so common. Sometimes it is honest. Sometimes it is also the easiest thing to sell: the engineer gets a clean repo, the agency gets a clean scope, and the founder carries the risk of rediscovering every edge case users already taught the old product. We have turned down rewrite contracts at appssemble for exactly this reason: the honest answer in most cases is "you don't need a rewrite, you need someone who can read your existing code and introduce seams."
The Strangler Fig: how grown-up engineering teams actually do this
Martin Fowler named the Strangler Fig pattern in 2004 after the vines he saw in the Queensland rainforest. The vine germinates in a nook of a host tree, sends roots down toward the soil, and grows around the host until the host can be removed. New software grows around the legacy system the same way: feature by feature, route by route, until the old system is no longer doing any work and can be deleted.
Fowler is clear that this still costs real work. You have to build transitional architecture so old and new code can coexist. The win is that the investment and the return become visible gradually instead of arriving as one risky launch.
The teams you've heard of usually run some version of this incremental play, not the big-bang play.
Slack rewrote their desktop client between 2017 and 2019. The post-mortem is literally titled "When a rewrite isn't." They defined a target architecture and strict legacy-interop rules: old code couldn't import new code directly, only through "exported" interfaces; new code couldn't import old code directly, only through "adapted" interfaces. The first piece of the new architecture they shipped to users was the emoji picker, two years before the full rewrite was finished. Then the channel sidebar. Then the message pane. There was no big-bang release and no week where users woke up to a completely unfamiliar Slack.
Shopify took the modular-monolith path. Their core Rails codebase has been worked on for more than a decade by more than a thousand developers. Instead of splitting everything into services, they reorganized around business components and later used Packwerk to enforce package boundaries in CI.
Twitter incrementally replaced subsystems too: message queue, tweet storage, then the search front-end, which produced a 3x latency drop in 2011. By US election day 2012, Twitter handled 327,452 tweets per minute. That is incremental migration and re-architecture under load, not a six-month freeze followed by a launch party.
Stripe's published migration playbook is even stricter: dual-write, compare old and new behavior in production, move reads, then writes, then delete the old path. Their own summary is the line founders should remember: "All changes were incremental, never attempting to change more than a few hundred lines of code at a time."
The lesson across all of them is practical, not ceremonial. Preserve working behavior. Put clean boundaries around the old paths. Extract one bounded context at a time. Run new code alongside old code with traffic shifting feature by feature. Keep the data layer stable as long as possible. Delete old code only when nothing calls it anymore. Ship value to users every two weeks throughout. Never go dark.
Five reasons incremental beats big-bang for a vibe-coded startup
1. You keep shipping to your users. Imagine you're running a small B2B tool with 300 paying customers, churning at 4% a month. A six-month rewrite means you ship zero customer-facing improvements for 24 weeks. With a 4% monthly churn rate, you lose roughly 22% of your base before the rewrite is even done, and they leave for whichever competitor shipped the integration they asked for. Incremental migration keeps your release cadence intact. You replace the auth module behind the scenes; the user just sees that login is faster.
2. You don't pay the second-system tax. Fred Brooks called the second system the most dangerous you'll ever design. The team building the rewrite is confident, well-rested, and quietly importing every feature you wisely cut from version one, plus generalizations you'll never use. Incremental work has no place to hide that bloat. Each piece has to justify itself against a working comparison.
3. The data stays where it is. Most rewrites don't fail at the code layer. They fail at the data migration. A vibe-coded MVP usually has weird data, three different "user" tables in Supabase that don't reference each other, JSON blobs holding business logic, foreign keys held together with hope. Incremental work lets you stabilize the schema as a separate workstream from the code, instead of doing both at once under launch pressure.
4. You discover what's actually broken versus what's just unfamiliar. Spend a week reading the existing code before you decide. Most founders find that large parts of the product are not broken enough to justify a rewrite. The real seams tend to be concentrated: auth, payments, reporting queries, background jobs, and whatever times out under load. Now you have a list of things to extract, ranked by pain. That's a roadmap. A rewrite is not a roadmap.
5. Investors read the difference. Technical due diligence reads whether you control the asset. A founder who can show old code shrinking month over month, new code with tests and observability, and no downtime reads as someone in control. A founder mid-rewrite reads as someone asking investors to fund uncertainty.
"But what if my code is genuinely unsalvageable?"
Sometimes it is. We're not selling a religion. A rewrite is the right call in five specific cases:
- You have under 50 paying users and no third-party integrations. The Spolsky calculus inverts when there's almost no embedded user behavior to preserve. Throw away the demo; build the product.
- The architecture has no seams at all. If the entire app is a single 4,000-line
App.tsxwith all the business logic in the React tree and no backend, your first project is introducing a real backend boundary. That may feel like a rewrite, but it should still be staged around the data and user flows you need to preserve. - The data model is incoherent and you have no production data worth keeping. Fix the schema once and start clean.
- Security is so broken that the existing user data is a liability. Sometimes the right move is to nuke the database, notify users, and start over with proper auth.
- You are a solo founder who didn't write any of the existing code. When there is no team continuity, reading unfamiliar code can cost more than writing fresh code. Spolsky's law inverts when "the team" is one person who has never seen the repo.
If none of those five describe your situation, the default is incremental.
Friendster is the counterexample that keeps this honest. Refusing to fix a scaling architecture can kill you too. The point is not "never rewrite." The point is to make the decision specific before you spend the money.
A six-question framework before you decide
Before you accept the rewrite quote, run this:
- Do you have paying users? If yes, default to incremental.
- Are there any seams at all, auth, billing, an email service, anything you could lift out? If yes, you can apply Strangler Fig.
- Is the data layer salvageable? If yes, keep it. Most rewrite pain is data pain.
- Can you ship visible value to users every two weeks during the work? If no, you don't have a plan. You have a death march.
- Are you rewriting because the code is bad, or because you don't understand it? Read it for a week first.
- Would a senior engineer who isn't getting paid by the rewrite hours recommend it? Most of the time the answer is no.
If at least four answers point to incremental, do incremental. If all six point to rewrite, then maybe rewrite, but with an explicit Slack-style coexistence plan, not a big-bang launch.
Before you sign the rebuild quote, ask for four artifacts: a seams inventory, a data-risk map, the first two modules to extract, and the rollback and observability plan. If the plan cannot ship one visible improvement inside two weeks, it is not a migration plan yet.
What the right partner does instead
The job of a senior engineering partner is not to validate the rewrite fantasy. It's to read the existing code, separate the parts that work from the parts that don't, name the seams, and replace one piece at a time. That work usually starts with a product design pass on the data model and the user-facing flows, because those are what need to stay stable while the engine room gets rebuilt underneath.
The "just rebuild it" advice is wrong because it treats your current product as worthless. It isn't worthless. It contains every lesson you've paid for in real customer behavior, every weird edge case Nancy hit, every payment retry your users tolerated, every integration your largest customer demanded. Throw it out and you also throw out the proof that any of it works.
If you're holding a rewrite quote and a list of paying customers, talk to us before you sign. We'll read the code, map the seams, and give you a rebuild/no-rebuild decision with the first extraction plan. If you are one of the five true rewrite cases, we will say so before you spend the money. Book a call.