Software rewrite: the wrong question every non-technical founder gets handed at the worst time

A field guide for founders being asked to fund a software rewrite: what the question actually means, why it almost always fails, and the four questions you should ask before signing anything.

Camila had been CEO for nineteen months when her lead developer walked into a one-on-one and said the line every non-technical founder eventually hears: “We need to rewrite this.” The product had real customers, monthly revenue, and an investor check that had cleared in February. The codebase was eighteen months old, built fast through pre-seed, and showing every fingerprint of the four contractors who had touched it. The developer wanted six months and a clean slate. The investor expected new features. Camila had no way to tell whether this was a serious engineering call or a junior developer’s allergy to inherited code.

A software rewrite is the decision to throw out an existing codebase and build a replacement from scratch, usually because the team believes the current system can no longer evolve at the speed the business needs. That is the textbook definition. The honest definition is rougher: a rewrite is what gets proposed when somebody on the team has lost faith in the code and can no longer separate the technical problem from the emotional one.

For a non-technical founder, the rewrite question is almost never the question that should be answered. It is three questions stacked on top of each other, and answering the wrong one is how an early-stage company burns a year of runway rebuilding what it already had.

Why “should we rewrite?” is the wrong question

The framing the developer hands you is binary. Keep the old code, or start over. That framing is what gets the rewrite funded, because both answers feel like decisions and one of them sounds like progress.

In practice, neither answer is what the business needs. The business needs to know what is hurting it. The codebase is one possible reason. There are usually four: the system genuinely cannot do what the customer needs (architecture); the team cannot ship safely (operational); the engineers do not want to work on it (cultural); or the founder cannot read what is happening (visibility). Each of those calls for a different intervention, and only one of them is a rewrite.

If you accept the binary, you have already lost the conversation. The question is not “do we keep it or start over.” The question is: what specific business outcome is the existing code preventing, and what is the smallest change that fixes it?

The three problems hiding inside the rewrite question

When a developer says the words “we need to rewrite this,” they are usually conflating three different problems. Pull them apart before you decide anything.

The business problem

Start here. Before any conversation about code, name the business outcome the current system is making impossible. Is it shipping the next feature without breaking the previous one? Is it the latency that’s costing you a flagship customer? Is it onboarding a new tier of pricing? Is it a security audit you need to pass to close enterprise? Is it none of those, and the real issue is that the developer is bored?

We have watched founders fund six-month rewrites because shipping had slowed down, only to discover six months later that shipping was slow on the new codebase too. The original problem was a missing staging environment and an undocumented deployment process. Neither of those required a rewrite.

If you cannot finish the sentence “if we do this rewrite, our company will be able to do X by Y date and Z will be measurably different,” you do not have a business problem. You have an engineering preference dressed up as a business problem.

The technical hypothesis

Once the business problem is named, the next question is: what technical change actually solves it? A rewrite is one option. It is rarely the cheapest option. It is almost always the slowest option. And it carries a specific risk that incremental changes do not: the new code has to reach feature parity with the old code before anybody can use it. That work is invisible to customers and investors. Six months of building things that already exist is one of the most expensive shapes a startup roadmap can take.

For most early-stage codebases, the cheaper hypotheses are: targeted refactors of two or three specific modules; a new service that handles the broken piece while the old system keeps running; a rewrite of a single layer (the data access layer, the auth layer) rather than the whole stack; or fixing the deployment, monitoring, and testing infrastructure so the existing code becomes safer to change. Most founders never hear these options because the developer who proposed the rewrite has already decided the answer.

The falsifiable bet

The third problem is the one that almost never gets articulated, and it is the one that separates real engineering decisions from wishful ones. Every rewrite proposal is a bet. Bets have a falsification condition: a way to know, in advance, what would mean the bet failed.

What is the metric that says this rewrite worked? Is it deployment frequency? Bug rate per release? Time to onboard a new engineer? Time to ship a feature that touches three modules? Customer-visible latency? Whatever it is, it must be measurable today, measurable on the rewritten system, and trustworthy from the founder’s seat without having to ask the developer. If the bet is “you’ll feel better about the code,” you are funding therapy, not engineering. This is the same logic we use to define what an MVP actually is: without a falsification condition, you have a project, not a bet.

The Joel Spolsky rule, 25 years later

In 2000, Joel Spolsky wrote what is still the most cited essay on the topic, Things You Should Never Do, Part I. His thesis: rewriting from scratch is the single worst strategic mistake a software company can make. Netscape lost the browser war to Microsoft because it spent three years rewriting Communicator while IE shipped. The line every founder should remember from that piece: “you are throwing away your market leadership.”

Twenty-five years on, the rule still holds for the case Spolsky was protecting: a production product with real customers, a working business model, and a codebase that has been seasoned by years of edge cases. Do not rewrite that. Refactor it.

What has changed is the situation Spolsky was not addressing. He was writing about Netscape. The codebase that walks through Pixel Breeders’ door in 2026 is more often an eighteen-month-old MVP, built by two contractors and a no-code stack, that was never engineered to last. It is not a battle-tested system. It is a prototype that survived contact with customers, and the patterns Spolsky was defending do not all apply.

For that codebase, the question shifts. It is not “should we rewrite Netscape.” It is “the prototype reached product-market fit faster than the engineering caught up. Now what?” That question has a different answer, and it usually involves rebuilding pieces of the system in parallel while the original keeps running. Not a full rewrite. Not a refactor. Something in between, with the same falsification discipline as a real bet.

Five questions to ask before you fund a rewrite

When the rewrite proposal lands on your desk, work through these in order. Most rewrites collapse on questions 1, 2, or 3.

1. What is the actual business loss this codebase is creating? Force a number or a date. Lost revenue, missed customers, a deal at risk, a regulatory deadline. “We can’t move fast enough” is not an answer. “Acme refused to sign their renewal because the export endpoint times out on files over 50MB, which is a $180K ARR loss” is an answer.

2. Can the developer name the single change that would fix 80% of the loss? Ask them to describe the smallest intervention that addresses the named problem. If they can name it in one paragraph, the rewrite is probably the wrong answer and the change is what you should fund instead. If they cannot, that is your signal that the rewrite is being proposed as a default, not as a decision.

3. Who is recommending the rewrite, and how long have they been with the code? Developers who inherit a codebase reach the “we should rewrite this” moment after about three months. It is a known psychological pattern, not necessarily a technical one. Senior engineers who have lived with a codebase for two years rarely propose rewrites. They propose targeted refactors. If the rewrite is being recommended by someone who joined six weeks ago and has only worked on one module, weight the recommendation accordingly.

4. Is this a single ship date, or a parallel system that has to converge with production? The honest answer is almost always the second one. Rewrites that run as “we’ll stop building features for six months and then switch over” have a ~10% success rate in our experience. Rewrites that run as “we’ll build the new thing alongside the old thing, migrate one feature at a time, and turn the old thing off when migration is complete” land closer to 60%. The first plan is a thing engineers say. The second plan is a thing engineers ship.

5. What does “done” look like, and is it measurable from the founder’s seat? Done is not “the new code is feature-complete.” Done is “we can ship feature X in N days instead of M days, and customer Y is using the new system in production with metric Z.” If the developer cannot define done in a way a non-technical founder can verify, the rewrite has no termination condition. A project without a termination condition does not end. It hires more developers.

When a rewrite actually is the right call

It can be. Four specific patterns are worth funding.

The first is the vibe-coded MVP that found product-market fit. We see this monthly. A founder shipped something in eight weeks using a hosted backend, three SaaS APIs, and a handful of LLM-assisted features they do not fully understand. It works. Customers pay. And every new feature breaks something else, because the system was never designed to do what it now has to do. In this case, the “rewrite” is closer to a proper first build. Spolsky’s rule does not apply because there is no working engineering to throw away; there is a prototype that should now be engineered. The framework we use for non-technical founders making this exact decision treats this as the natural transition from “what we built to learn” to “what we build to scale.”

The second is the platform shift the business model now requires. You launched a web app; you now need a mobile-first product because the customer base moved. You built on a database that cannot handle the next order of magnitude. You picked a no-code stack and the next pricing tier costs more than rebuilding it. These are not rewrites of preference. They are rewrites of fit.

The third is the security or compliance gate. SOC 2, HIPAA, PCI, LGPD, GDPR. Some compliance regimes are reachable from the existing code with auditable effort. Some are not. When the existing architecture cannot pass the audit without changes deeper than the original design supports, the rewrite is real, and the cost is the cost of doing the business you are now in.

The fourth is the irreplaceable engineer who quit, leaving a codebase nobody can read. This is the most controversial case, because the right move is usually to hire a new engineer to learn the codebase rather than rewrite it. But there is a threshold. When the codebase is small enough, the documentation is bad enough, and the people who can read it have all left, sometimes the cost of learning is higher than the cost of rebuilding with a team that can maintain the new thing. This is rare. If it sounds like your situation, get a second opinion from someone who does not stand to bill the rewrite.

A 4-week test before you fund the rewrite

If after the five questions you are still considering it, do not sign the rewrite. Run a four-week test first.

Pick the single most painful feature or module, the one that comes up every time the team complains about the codebase. Pick the falsification metric you agreed on in question 5. Give the team four weeks to either refactor that one piece in place, or extract it into a parallel service, and to demonstrate measurable improvement on the metric.

Four weeks is roughly $20K to $50K of engineering time for an early-stage team, depending on rates. A full rewrite is six to twelve months and $150K to $600K at the same rates, and that is before the second-year maintenance costs you will inherit on whatever ships. The four-week test is the cheapest possible way to learn whether the team can change this system at all.

If they can: the rewrite is the wrong answer; keep refactoring. If they cannot: now you have evidence, not opinion, and the rewrite conversation can happen with everyone looking at the same data.

Frequently asked questions

What is a software rewrite? A software rewrite is the decision to discard an existing codebase and build a replacement from scratch. It usually replaces the original code in entirety, not piece by piece, and aims to reach feature parity with the old system before customers see anything new.

When is a rewrite the right answer? Rarely. The defensible cases are: an MVP that found product-market fit and needs to be properly engineered for the first time; a platform shift the business model now requires; a compliance regime the original architecture cannot reach; or an unmaintainable codebase whose original engineers have left. In every other case, a targeted refactor or a parallel service is cheaper and faster.

How much does a software rewrite cost? For an early-stage product, a real rewrite typically runs six to twelve months of engineering, which is roughly $150K to $600K in the US and R$ 300K to R$ 1.2M in Brazil depending on team size and seniority. That number excludes the ongoing maintenance cost of operating two systems during migration and the opportunity cost of features not shipped during the rewrite. The hidden cost of a rewrite is what you stop building while it happens.

Should I rewrite or refactor? Refactor by default. Refactoring is incremental, lets you ship customer-visible value during the work, and has a much higher success rate. Choose a rewrite only when the existing code cannot reach the destination through any incremental path. The “rule of 3” (refactor when you see the same pattern three times) is a useful internal heuristic but does not extend to entire codebases. Whole-system rewrites are not refactors at scale; they are a different kind of bet with different failure modes.

Why do most software rewrites fail? Three reasons, in order of frequency. They do not finish before the runway runs out, because feature parity is more work than the team estimated. They ship without the falsification metric being met, so nobody can tell whether the rewrite worked. And they trade one set of problems for another, because the team that wrote the original code is often the team that wrote the rewrite, with the same assumptions.

If you are reading this in the middle of a rewrite conversation, the most useful thing you can do tomorrow is not approve the rewrite. It is to ask question 1 and refuse to move forward until you have a number.