When to refactor vs rebuild a vibe-coded app

It depends on the data model, not the code

Founders usually ask this question because the code looks messy. Files run to a thousand lines, the same logic appears in four places, and every prompt seems to break something. That feels like a reason to start again. Usually it isn't.

Messy code can be tidied. Components can be split, duplicated logic pulled into one function, and error handling added screen by screen. What is expensive to change later is the shape of the data: what the tables are, who owns each record and how they link together. Every screen, every query and every access rule depends on it.

So the first question is not "is the code good?" It is "does the database describe my product correctly?" If it does, refactor. If it doesn't, and you have to change it in many places at once, a rebuild is often cheaper than surgery.

The second question is whether you can get the code out at all. If the app lives on a platform you can't export from cleanly, the choice is made for you.

Why the classic advice only half applies

In 2000, Joel Spolsky called rewriting code from scratch the single worst strategic mistake a software company can make. His example was Netscape, which went years without shipping while it rebuilt its browser. His argument was that old code is full of bug fixes found through real-world use, and a rewrite throws that knowledge away.

That argument holds for a product with years of users. A vibe-coded app is usually a few weeks or months old, with few real users and few hard-won fixes in it. There is much less hidden knowledge to lose.

What a vibe-coded app does hold is your product decisions. The screens, the flows and the copy are a working specification, which makes a rebuild faster than the first build. And if real users have signed up, it holds their data, which has to come with you whatever you decide.

Signs refactoring will work

• You can explain every table in one sentence, and each record has one clear owner.
• Access rules exist and are roughly right, even if some are missing.
• The app is built on a stack you would choose anyway, such as React or Next.js with Postgres.
• The code is in a Git repository you control.
• The problems are local: a page that crashes, a form with no validation, a layout that breaks on phones.
• A developer can fix a bug by hand in an hour or two without breaking something else.

Signs a rebuild is cheaper

• The same thing is stored in several places, or relationships are stored as text instead of links between tables.
• There is no clear owner on records, so access rules can't be written without changing the schema.
• Secret keys are used in the browser, and moving them to the server means rewriting most data access.
• Every change in one place breaks something unrelated, even when done by hand.
• The code can't be exported, or only exports in a form you can't run outside the builder.
• The product has changed so much since the first prompt that half the screens are no longer needed.

The decision table

The last row cuts both ways. Real users make refactoring safer, because the app keeps working while you fix it. No users make rebuilding cheaper, because there is nothing to migrate.

Three common situations

These are common patterns, not specific clients.

The tidy-looking app with a broken data model. The screens are good and the design is consistent. But the database stores, for example, the organiser's name as text on every booking rather than linking to an organiser record. Changing that means touching every query. Here I would keep the screens as a reference and rebuild the data layer, then reconnect the screens one by one.

The messy app with sound foundations. Components are huge and copied around, there is no error handling and the mobile layout is broken. But the tables make sense and the access rules mostly work. That is a refactor. Two or three focused passes leave you with an app that is much easier to change.

The app that outgrew its prompt. The product has pivoted twice. Half the tables belong to features nobody uses. If nobody depends on it yet, a clean rebuild of the current product, with the old app as a clickable specification, is usually quicker than deleting your way to it.

The middle path

Most decisions end up in between. Martin Fowler calls this a strangler fig approach: rather than one big rewrite, you build new parts alongside the old system and move behaviour across piece by piece until the old code can be removed.

For a vibe-coded app, that usually looks like this:

1. Keep the database, fixing the schema where it is wrong, with migrations that move existing data.
2. Move secret keys and sensitive logic to the server first, because that is where the risk is.
3. Replace the most important journey next, such as sign-up to first value, or checkout.
4. Replace the remaining screens as you touch them for other reasons.
5. Delete old code as soon as nothing uses it.

The app keeps working the whole time, and users never see a big switchover. The risk is that it drags on, so set an end date for the old code.

How to decide in a week

You don't need weeks of analysis. A few days of looking at the right things is enough.

1. Get the code into your own repository. If you can't, that answers the ownership question.
2. Draw the data model on one page. If you can't, or the drawing doesn't match how you describe the product, that is the biggest signal.
3. Check the access rules and keys. Supabase's docs say a secret key bypasses every Row Level Security policy and must never be in a browser or source control. If yours is, find out how much code depends on it.
4. Fix one real bug by hand. Time it. Note what else broke.
5. List the screens you still need. Compare it with what exists.

Then put the findings next to the table above. If you want help with steps 2 to 4, that is what the free vibe-code health check is for.

What each route costs

A refactor is usually cheaper up front and keeps the app live. A rebuild costs more up front but can be cheaper over the next year, because every later change is faster. I go through the numbers, with UK day rates, in what a vibe-code rescue costs in the UK.

Whichever way you go, the next person to work on the code needs to understand it. How to hand a vibe-coded app to a developer covers what to prepare, and the vibe-code rescue checklist lists everything I check before recommending either.

When to get help

If the signs above point clearly one way, you may not need anyone to tell you. If they are mixed, which is common, a second opinion is cheap compared with picking wrong. My guide to fixing a vibe-coded app covers the wider picture.

A Rescue Sprint starts from the free health check and ends with the fixes done, not just a report. If the honest answer is a rebuild, I will say so and scope it like an MVP Build.