Almost never. The case against rewriting is older than your product, and it applies more strongly to solo founders than to anyone else — because you don’t have a team to keep the old system running while you rebuild.
Methodology. The argument here builds on Joel Spolsky’s Things You Should Never Do, Part I (joelonsoftware.com, 2000) and Martin Fowler’s Strangler Fig pattern. Both essays remain the canonical references on legacy-system replacement. How we research.
In April 2000, Joel Spolsky wrote what is still the single most important article ever written about rewrites. His argument: when Netscape decided to throw out their working browser and rewrite from scratch, they handed the market to Microsoft. The old code — ugly, undocumented, full of inscrutable patches — encoded years of bug fixes that nobody could remember the reasons for. Throwing it out meant rediscovering all of those bugs, one by one, while shipping nothing. Spolsky called it “the single worst strategic mistake that any software company can make.”
The argument applies more strongly to solo founders than to Netscape. Netscape had hundreds of engineers; some of them could keep the old browser shipping while others worked on the rewrite. You don’t. If you rewrite, you stop shipping for however long the rewrite takes. Your existing customers receive zero new features and zero bug fixes during that period. Your support burden doesn’t go down. Your churn doesn’t pause. The old code keeps generating bug reports and edge cases that you now have to fix in a system you’ve mentally written off.
And the rewrite always takes longer than you think. Always. The estimate that lives in your head is “six weeks.” The reality is six months minimum, typically eight or nine, sometimes never. Solo founders who start rewrites tend to abandon them around month four, when the new system has feature parity for about 60% of the old system and the next 40% is the hard parts — auth edge cases, billing prorations, the migration script, the data backfill, all the things that were boring to write the first time and are equally boring to write the second time. The rewrite stalls; the old system is now neglected; the founder has effectively done nothing useful for four months.
Ugly code that ships and earns money is more valuable than clean code that doesn’t exist. Customers don’t see your code; they see your product. The ugliness is usually a story you tell yourself about why the business isn’t growing — but the ugliness isn’t why. Distribution is why, or pricing is why, or positioning is why. Rewriting hides those harder problems behind a code project that feels productive.
Your customers do not know what framework you use. They cannot tell whether your backend is Rails 5 or Rails 7, whether your frontend is Next.js 12 or Next.js 15, whether you’re on Vue 2 or Vue 3. The pressure to “modernise” is internal, not external. Modernisation is fine as a long-term project; it’s catastrophic as a justification to throw out a working system.
Solo founders often conclude their architecture is wrong because they’ve learned more about the domain than they knew when they wrote the original code. This is normal and good. It does not mean the architecture is wrong; it means you understand the domain better. A rewrite based on your current architectural taste will be better than the original code, and worse than what you’ll write 18 months from now — at which point you’ll want to rewrite again. There’s no end-state where you’re finally smart enough.
This is occasionally true and usually false. The honest test: can you add a feature in two days that you could add in two days a year ago? If yes, the codebase isn’t the problem — you’re bored or distracted. If no, find the specific subsystem that’s blocking you and refactor it in place. The blockage is almost never the whole codebase. It’s usually one or two modules that have accumulated too much complexity.
Maybe. Maybe not. The tools have improved a lot since 2018 — our writeup on building SaaS with Claude covers what’s changed. But the productivity gain from new tools is usually less than the productivity loss from re-implementing your existing system in them. Use the new tools for new features, not for replacing what already works.
There are real ones. They’re narrower than founders typically think.
Not “the architecture makes security hard.” That’s case 3 below. This is “the framework version we’re on has a known unpatched RCE and the upstream is unmaintained.” If your auth library was abandoned by its maintainer and there’s no migration path, you may need to swap the auth subsystem out, which can cascade into a partial rewrite. Even here, the goal is to replace the affected subsystem — not the whole product. Rails 4 to Rails 7 is a partial rewrite. PHP 5 to anything is a partial rewrite. The point is to pick the smallest possible scope.
The framework no longer ships security patches. The hosting provider for your stack is shutting down. The language version is removed from major package registries. These are real and they happen — the GoDaddy classic-PHP shutdown, AngularJS’s end-of-life, Node 12 dropping from npm registry policies. When the substrate is genuinely going away, you have no choice. Plan the migration deliberately, do it module-by-module, and budget twice as much time as you think.
Rare but real. If your data model has a structural flaw — say, you assumed one user has one workspace, and now you’re building multi-workspace and the assumption is baked into 200 places — the cost of patching it in place may exceed the cost of restructuring. The signal: you’ve tried to add the feature three times, each attempt has produced data corruption, and the workarounds have made the code worse. Even here, the answer is usually “rewrite the data layer” not “rewrite everything.”
Identify the single module that’s causing 80% of your pain. Replace it. Keep the rest. This is unglamorous; it’s also what works. The whole codebase isn’t broken — one part is. Find that part. Refactor it over two weeks. Notice that the rest of the system is fine.
If you’re genuinely on a dying stack, replace one module at a time while keeping the rest of the system live. Auth first, often. Then billing. Then the worst-feeling page. Each module replacement is a contained project with a clear “done” state. The full transition takes longer than a rewrite would, but you keep shipping the entire time, which is the whole point.
Martin Fowler’s strangler-fig pattern is the canonical answer for this. Stand up a new system alongside the old one. Route specific endpoints to the new system as they’re built. Over months or years, the new system grows around the old one, and at some point the old system has nothing left to do and gets removed. There’s no big-bang switchover, no period where the old system is broken and the new one isn’t ready. This is the right pattern for almost every “but the architecture is wrong” case.
Modern coding assistants are extremely good at the kind of mechanical refactor work that used to make in-place modernisation painful — renaming patterns across a codebase, migrating syntax, generating tests for legacy code that lacks them. If your reluctance to refactor is because the work feels tedious, the tools have changed since you last tried. Pair this with deliberate choice of host and database when modules are replaced — our Vercel vs Railway and Supabase vs Neon writeups cover the choices that matter for incremental migration.
Most rewrite ambitions hide a founder who is bored. The product works, it earns money, the next steps are unglamorous — sales, content, customer development, support — and the founder doesn’t want to do those things. A rewrite gives them an excuse not to: they’re “rebuilding the foundation” and won’t be ready to talk to customers for six months. By month four, they’re tired of the rewrite too, but now they’ve sunk months into it and there’s nothing in production to show for it.
The therapy version of this advice: ask yourself why you want to rewrite. If the answer involves the words “clean,” “modern,” or “proper,” you’re reaching for a fix that won’t fix the actual problem. The actual problem is usually growth, distribution, pricing, or positioning. None of those are solved by code. If you’re considering a rewrite to escape an unrelated problem, recognising that is most of the cure.
The pragmatic version: don’t rewrite. Use AI tooling for refactors. Replace modules incrementally. Use the strangler pattern. If you’re starting fresh on a new product, pick a stack you can live with for a decade — our SaaS boilerplate guide covers the current durable choices. The product you have, however ugly, is more valuable than the prettier product that doesn’t exist yet.
One more honest qualifier. There is exactly one situation where a clean-slate rebuild is sometimes the right call: very early in a product’s life, when you have fewer than 50 users, the codebase is under 10K lines, and you genuinely picked the wrong substrate. Throwing out a one-month prototype is fine. Throwing out a three-year revenue-generating product is what Spolsky was warning about. Don’t confuse the two.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.