When to Rewrite vs Maintain Your Codebase Rebuild Decision

Deciding when to rewrite vs maintain a codebase is one of the highest-stakes calls you will make as a builder. Get it wrong in the "rewrite" direction and you lose months rebuilding what already worked. Get it wrong in the "maintain" direction and you spend years fighting a codebase that is fundamentally broken. This framework gives you a repeatable scoring method so you stop making this call on vibes.

Why Rewrites Are Tempting (and Dangerous) for AI-Built Apps

Joel Spolsky wrote the canonical warning against rewrites in 2000. His argument: your existing code, however ugly, contains years of accumulated bug fixes and edge-case handling that are invisible in the source but essential in production. Rewriting means throwing away all of that accumulated knowledge. The new code will look cleaner, but it will have all the bugs the old code fixed five years ago.

That argument was correct in 2000 and still holds for human-written codebases with years of production history. It was especially true when rewrites took six to eighteen months.

AI-built apps change the calculus in two important ways.

First, AI-assisted rewrites are dramatically faster. A codebase that would have taken a team of four engineers six months to rewrite can now be rebuilt in two to four weeks with focused AI pair programming. The "years of lost work" risk collapses when the rebuild timeline compresses by 90%.

Second, AI-generated code has different failure modes than hand-written code. Human code accumulates subtle domain knowledge over years of patching. AI-generated code is often structurally coherent but built on flawed initial assumptions; the codebase looks clean but the architecture does not fit how the product actually evolved. You end up maintaining a codebase that was never designed for where your product is today.

This does not mean rewrites are always right. The temptation is still real and still dangerous. Founders use "technical debt is too high" as a rationalization for avoiding the harder work of understanding and extending existing systems. Senior devs use it as a career move, because greenfield is more interesting than maintenance. The bias toward rewriting is human, not technical.

The antidote is a structured scoring framework instead of intuition.

The Decision Framework

Score your codebase on five axes. Each axis gets a score from 1 to 3. Add them up. The total guides your decision.

Axis 1: Can you deploy?

Score 1 if your deploy process is manual, fragile, or takes more than 30 minutes. Score 2 if you can deploy with one command but it breaks occasionally. Score 3 if deployments are automated, reliable, and reversible. A codebase you cannot confidently deploy is a codebase you cannot safely extend. If your score is 1 here, that problem alone can justify a rebuild, because every new feature requires you to navigate a minefield just to ship it.

Axis 2: Can you debug?

Score 1 if diagnosing a production bug takes more than a day of archaeology. Score 2 if you can usually find bugs within a few hours but the process is painful. Score 3 if you have good observability, clear error traces, and reproducible local environments. AI-generated codebases often score low here because logging and observability are rarely in the initial prompt. If debugging takes longer than building features, the maintenance cost is already unsustainable.

Axis 3: Can you extend?

Score 1 if adding a new feature requires touching more than five files you did not plan to touch. Score 2 if extension is possible but the coupling is uncomfortable. Score 3 if new features can be added in isolated modules without rippling through the rest of the system. High coupling is the most common reason AI-generated apps become maintenance nightmares. Everything calls everything else, and the context window explosion from making any change is enormous.

Axis 4: Is performance acceptable?

Score 1 if users are hitting latency or memory issues regularly. Score 2 if performance is acceptable today but has no headroom for growth. Score 3 if performance is solid and you have profiling data to back that up. Performance problems that are architectural (wrong data model, wrong caching strategy, synchronous where async is needed) rarely get fixed through optimization. They require structural changes that often amount to a partial or full rewrite anyway.

Axis 5: Is security adequate?

Score 1 if you have known vulnerabilities, unvalidated inputs, or secrets in the codebase. Score 2 if security is probably fine but you have not audited it systematically. Score 3 if you have done a security review, dependencies are current, and you have clear auth and validation patterns throughout. AI-generated code frequently introduces security issues through inconsistent patterns, because the model does not maintain global context about your security strategy.

Reading the scores:

• 13 to 15: Maintain and extend. Your foundation is solid.
• 9 to 12: Targeted refactoring. Fix the low-scoring axes without a full rewrite.
• 5 to 8: Serious consideration for rewrite. The foundation has multiple structural problems.
• Below 5: Strong case for rebuild. You are paying compound interest on bad foundations.

With a score in hand, the next question is how you actually execute the decision. A low score does not always mean a full rebuild is the right move.

How Do You Decide When to Refactor vs Rewrite

Even when your score suggests a rewrite, the strangler fig pattern is usually the better path. The strangler fig grows around an existing tree, gradually replacing it while the original tree continues to provide structure. In software, you build the new system incrementally alongside the old one, routing more and more traffic to the new system until the old one can be safely removed.

The pattern works like this. Identify the highest-pain component in your existing system. That is your first target. Build the replacement in isolation with the architecture you actually want. Wrap the old component behind an interface. Flip the switch and point callers at the new implementation. Once the new component is running in production without issues, delete the old one. Then move to the next component.

This approach preserves the parts of your system that are working while systematically replacing the parts that are not. It ships value continuously instead of going dark for two months while you rebuild. It lets you validate your new architecture decisions in production before committing to them everywhere.

The strangler fig is not always possible. Sometimes the architecture is so deeply coupled that you cannot isolate a single component without effectively rebuilding everything. Sometimes the new architecture requires a fundamentally different data model, and there is no clean migration path. In those cases, a phased rewrite with a clear migration plan is the right call.

One additional heuristic: if you are rewriting primarily to use a new technology (migrating from REST to GraphQL, from a monolith to microservices, from one framework to another), the strangler fig almost always beats a full rewrite. If you are rewriting because the domain model is wrong and the product has evolved in a direction the original architecture could not anticipate, a clean break may be genuinely necessary.

The Vibe Coding Advantage in Rewrites

Here is what changes when AI is in the loop: both sides of the equation get better simultaneously.

Rewrites get faster. A codebase that took a team six months to build can be rebuilt in two to four weeks when you use AI pair programming intelligently. The "sunk cost" of throwing away the old code is dramatically lower. The momentum argument for keeping bad code ("we cannot afford to lose those months of work") collapses when the rebuild is measured in weeks.

Maintenance gets easier too. AI excels at understanding existing codebases, explaining undocumented decisions, and making targeted changes with minimal side effects. Tasks that used to require the original author (because only they understood the subtle logic in a module) can now be handled by a developer who has been on the project for a week, with AI bridging the context gap.

This creates a genuinely new tradeoff. In the pre-AI era, the cost of maintenance decreased over time as developers built familiarity with the codebase. The cost of a rewrite was high and roughly constant. So you held on to the existing codebase longer.

With AI, the maintenance cost curve is flatter (AI reduces the familiarity premium) and the rewrite cost curve is lower (AI compresses rebuild time). The crossover point where a rewrite becomes preferable comes earlier in the lifecycle of a codebase.

The practical implication: AI-built codebases have a shorter useful life than hand-crafted codebases. If you built your MVP with AI in six weeks, you should plan to reassess the architecture at twelve to eighteen months, not five years. The velocity gain on the front end is real; so is the shorter architectural runway.

What This Means For You

The rebuild decision lands differently depending on where you are in your career and product journey.

If you are a founder or indie hacker:

• Your score on the "can you extend" axis is probably the most important. If new features require touching everything, your velocity will grind to a halt exactly when you need to move fastest.
• Do not let the sunk cost of the existing codebase override the framework. Two weeks of rebuild time is often cheaper than six months of dragging the existing architecture through new features it was not designed for.
• Use the strangler fig when you have users and need to ship continuously. Use a clean rebuild when you have a clear gap before your next major milestone.

If you are a senior developer or career changer:

• The framework gives you the vocabulary to make this case to stakeholders. "We should rewrite this" is easy to dismiss. "Our codebase scores 6 out of 15 on these five axes, and here is what that means for velocity over the next six months" is harder to ignore.
• Your judgment on the security axis matters most, because founders and junior devs consistently underweight it. A codebase with systematic security issues needs fixing regardless of what the other scores say.
• Incremental wins via the strangler fig build your credibility to advocate for larger architectural changes. Show the pattern working on one module before pitching a full rebuild.

If you are learning and building:

• A low score is not a failure. It means you built something and learned something. The codebase that got you here does not need to take you to the next stage.
• The most valuable skill is developing the instinct for when you are fighting the architecture versus when you are fighting normal complexity. Fighting the architecture feels like every change breaks something else. Normal complexity feels hard but contained.
• Rebuild with explicit goals. "I am rebuilding to practice the strangler fig pattern" or "I am rebuilding to fix the data model" will teach you more than "I am rebuilding because this code is bad."

The decision to rewrite or maintain is ultimately a bet on where your time compounds best. A clean codebase compounds: every new feature builds on solid ground. A tangled codebase decays: every new feature is slower than the last. The framework above helps you measure which situation you are actually in, separate from the storytelling you might be doing about it.