Should you rewrite your vibe-coded app? A rescue-or-rebuild decision tree

Do not approve a rewrite because somebody called the code "AI slop."

That phrase tells you how the reviewer feels. It does not tell you whether customers can keep using the product, which part creates business risk or whether replacing it would improve anything.

Some AI-built applications need serious structural work. Some need one contained repair and a release process. Others are doing their job and should be left alone.

The decision needs evidence from the running product, not an aesthetic reaction to the repository.

Start with four possible answers

"Keep it" and "rewrite it" are not the only choices.

There are four useful outcomes:

1. Keep it. The current stack and code are good enough for the product's stage. Add missing instructions and continue.
2. Stabilize it. Repair a defined set of production risks while the product stays in place.
3. Replace it in phases. Move one subsystem, workflow or interface at a time while customers continue using the rest.
4. Rebuild it. Create a replacement because the current foundation cannot support the required product safely or economically.

Most arguments become clearer once all four are allowed.

Keep the application when the problems are local

Messy code is not automatically expensive code.

Keeping the application is reasonable when:

• Customers can complete the core paid workflow.
• The current deployment can be reproduced from a company-controlled source.
• Authentication and customer boundaries can be tested.
• The database represents the business well enough to support upcoming work.
• Failures are contained to identifiable areas.
• A new developer can change one part without unknowingly changing five others.
• The hosting and platform constraints are acceptable for the next stage.

The repository may still have duplicate components, awkward names and generated abstractions nobody would choose by hand. Clean those only when they slow down a real change or hide a real risk.

A cleanup project without a production outcome can consume the same attention as a feature while leaving the business exactly where it started.

Stabilize when the product works but the operating layer is missing

This is common after a fast founder build.

The screens and core logic work. Customers receive value. The missing parts sit around the product:

• Production access is too broad.
• Releases go directly from an agent session to customers.
• Important jobs fail without an alert.
• Permission policies exist but have not been tested between customer accounts.
• Backups exist but nobody has restored one.
• Billing behavior depends on several handlers with no written state model.

None of these automatically requires replacing the application.

A stabilization project makes the current system safer to operate. It can add a staging path, critical-flow tests, monitoring, a restore procedure and a small number of structural fixes. The product stays recognizable, and the founder does not pay to rebuild working behavior.

Replace one part when the boundary is clear

Sometimes one subsystem has become the ceiling while the rest still earns its place.

Examples include:

• A no-code backend that now constrains data access or performance
• A mobile client that cannot support the required native behavior
• A billing implementation that needs one authoritative state model
• A reporting path that overloads the transactional database
• An authentication layer that cannot meet a current customer requirement

The important condition is a clean boundary. The old and new systems need a written agreement about which one owns each piece of data and behavior during the transition.

Do not let both systems accept conflicting writes to the same records. Move ownership deliberately, one boundary at a time.

This is why phased replacement can be safer than a big cutover. The old product keeps serving customers while each new part proves itself. It is not free. Running two systems creates synchronization and operating work. That cost belongs in the plan.

Rebuild when the foundation blocks every responsible path

A full rebuild becomes reasonable when several structural problems are true at the same time.

Strong signals include:

• Nobody can reproduce the running application from a controlled source.
• The data model contradicts the product and every important feature works around it.
• Customer separation cannot be enforced without changing the core architecture.
• The application depends on abandoned services or inaccessible accounts that cannot be isolated.
• Ordinary changes repeatedly break unrelated areas because responsibilities have no boundary.
• The required commercial or regulatory behavior cannot be added to the current stack.
• A phased transition would cost more or carry more risk than a controlled replacement.

Even here, "rebuild" does not mean start coding immediately.

The existing product is the best specification the replacement has. Map its user roles, states, integrations, data and failure behavior first. Decide which behavior must survive and which accumulated feature should be allowed to die.

Otherwise the new codebase repeats the old uncertainty in a newer framework.

Run this decision tree

1. Is the product commercially worth preserving?

If the product has no committed users, important operation or validated demand, a technical rebuild may be solving the wrong problem. Stop before spending five figures on code nobody has proved should exist.

If customers depend on it, continue.

2. Can you identify the current production source?

If yes, record it and continue.

If no, establish control before discussing architecture. The first project is a takeover, not a rewrite.

3. Can the critical customer paths be tested?

If the team can describe and verify signup, permissions, billing and the core workflow, the product has a basis for repair.

If nobody can define the expected behavior, map it from the running application before choosing a replacement.

4. Are the dangerous failures contained?

One weak integration can be stabilized. A permission model that leaks through every route may require a deeper replacement.

Name the boundary. Avoid conclusions like "the architecture is bad" when the evidence points at one subsystem.

5. Can the new and old systems coexist safely?

If each data type and workflow can have one owner during transition, phased replacement is available.

If the product cannot operate during a partial move, compare a planned full cutover with the cost of stabilizing the current system first.

6. What decision would you make if nobody sold rebuilds?

This catches an incentive problem.

An agency that earns more from a rebuild should show why repair and phased replacement do not fit. A freelancer who only fixes bugs should still admit when the foundation is beyond a sensible repair.

Ask for the evidence, alternatives and assumptions in writing.

What a responsible recommendation contains

A rebuild recommendation should include:

• The current business-critical paths
• The specific structural blockers
• Repairs considered and why they are insufficient
• Parts worth preserving
• Data and integration migration plan
• Coexistence or cutover method
• Verification and rollback plan
• Cost by independently useful phase
• A clear statement of what remains unknown

If the recommendation is only "the code is messy," you do not have a scope yet.

The 10-Day Production Takeover is allowed to conclude with any of the four answers: keep, stabilize, replace in phases or rebuild. The costs of those scopes are different, which is the point of inspecting the product before selling the next project.