Should I fix or rebuild my Lovable app?

Score the five signals. Lovable apps usually score well on stack and data model and lose points on security (RLS) and coherence (duplicated components). Most land at 7 or 8 — fix, with security first. Rebuild only if the core flow has never worked for a real user.

Should I fix or rebuild my Cursor project?

Cursor projects usually work but lose points on coherence and stack consistency (mixed framework versions, several patterns per concern). Most are fix-with-consolidation. Rebuild if it has never built cleanly or the framework is a hybrid the model invented.

How do I know if the core flow 'has ever worked'?

One real person, not the builder, completed the app's main action in an environment other than the AI tool's preview. If that's happened, score 2. If only you have, in the preview, score 1. If it's never completed anywhere, score 0.

Is a rebuild always more expensive?

Not always. For a codebase scoring 0–4, understanding it costs more than rewriting it. But rebuilds are consistently underestimated because the requirements are scattered through the old code. Phase it: first working version in two weeks, rest after.

Can I run this test myself?

Three of the five signals (core flow, stack, coherence) a careful non-technical founder can score. Data model and security need an hour from an engineer. Our free audit tool checks part of it automatically.

Vibe coding

Fix or rebuild? A decision framework for AI-generated codebases

Author

AI Cubed

Published

September 9, 2026

Read time

10 min

Every founder with a messy AI-built app eventually asks the same question, and gets three different answers from three developers. One says it's fine. One says rebuild. One wants a retainer to find out. The reason the answers differ is that "fix or rebuild" isn't one decision — it's five signals and a scope question, and most people are guessing at all six.

This is the framework we use in every audit. It's deliberately simple enough that a non-technical founder can follow the reasoning, and specific enough that two engineers applying it to the same codebase should land on the same answer.

The five-signal test

Score each signal 0, 1 or 2. Be honest — the framework only works if the scores are. If you can't assess a signal yourself, that's the one to ask an engineer to check; it's an hour, not a project.

Scoring the five signals
Signal	0 — points to rebuild	1 — mixed	2 — points to fix
Core user flow	Has never worked end to end anywhere	Works in one environment with workarounds	Works end to end for at least one real user
Data model	Schema reshaped repeatedly; tables contradict the product	Roughly right, missing constraints and indexes	Tables match the product; relationships make sense
Stack	Obscure, abandoned, or several frameworks glued together	Mainstream but mixed versions or conventions	Mainstream, one version, current
Security	Leaks by design — everything runs client-side, no server boundary	Gaps but fixable: missing RLS, keys in client	Server boundary exists; policies exist; gaps are small
Coherence	Contradictory patterns per file; huge duplication; nobody can find anything	Two or three patterns per concern; readable with effort	Consistent patterns; a competent engineer can navigate it in a day

Add the five scores. Eight to ten: fix it — the foundation is real and the remaining work is additive. Zero to four: rebuild — you would spend more understanding it than writing it. Five to seven: neither answer is right for the whole app, which brings us to the part most people skip.

The module-level decision (where most real apps land)

A codebase is not one thing. It's an auth module, a data layer, a payments integration, a dozen screens, some background jobs. In a middling codebase, some of those are fine and some are disasters, and the right move is to decide for each one. Draw a table with one row per module and apply three tests.

Keep, refactor, rewrite or delete — per module
Does it work?	Can an engineer read it?	Is it cheap to test?	Decision
Yes	Yes	Yes	Keep. Don't spend money on code that isn't costing you anything.
Yes	Yes	No	Keep, add a test around its edges.
Yes	No	—	Refactor. It works; make it readable before the next change breaks it.
No	Yes	—	Fix. The bug is findable.
No	No	—	Rewrite. Cheaper to write it properly than to understand it.
Unreachable from any route or job	—	—	Delete. Dead code is a cost with no benefit — usually 20–40% of an AI-built codebase.

This is what an audit produces: that table, filled in, with a quote attached. It's also why cost tracks the number of rewrite rows rather than total lines. A large codebase where most modules are keep or refactor is cheaper than a small one where everything is tangled.

Three illustrative cases

These are composites, not client stories, chosen to show how the scoring plays out.

A Lovable-built CRM with real users. Core flow 2, data model 2, stack 2, security 1 (RLS missing on three tables), coherence 1 (the same list component exists four times). Total 8: fix. Security first, consolidate the components, add tests around contact creation. Two to three weeks.
A Cursor-built marketplace that never took a real order. Core flow 0, data model 1, stack 1 (Next 14 and 15 conventions mixed), security 1, coherence 0. Total 3: rebuild. Keep the schema idea and the UI screens as reference; rewrite from a clean scaffold. Four to eight weeks, first working version in two.
A Bolt-built internal tool with one branch using it. Core flow 2, data model 1, stack 2, security 0 (everything client-side against a public database), coherence 1. Total 6: per module. The UI is kept; the data layer is rewritten behind a server boundary with policies; the reporting job is deleted because nobody uses it. Three to four weeks.

Why not just rebuild — it's cleaner?

Because the AI's work is real and rebuilding discards it. Screens that users have validated, a data model that fits the product, integrations that took days to get right — all of it gets rewritten from memory, with new bugs. Rebuilds also take longer than anyone estimates, because the first version's requirements are now scattered across a codebase nobody wants to read. Rebuild when the test says rebuild. Not because it feels tidier.

Why not just clean it up file by file?

Because a large share of the files should be deleted, and cleaning them first is paying to polish garbage. The module map identifies what's reachable and what isn't before anyone touches a line. Cleanup without a map is how six-week engagements become sixteen.

Whichever you choose, do these first

Rotate any secret that was ever in the repo or the browser.
Get the database behind access rules, even if you're going to rebuild — your current users' data is exposed now, not later.
Put the code in real version control with a branch you can go back to.

These are identical for fix and rebuild, they take a day or two, and they're the difference between a project and an incident.

What AI Cubed does about this

Our two-business-day audit applies this test and produces the module table with a fixed quote. Most apps we see are fix or per-module; we tell you on day two if yours is a rebuild. See vibe-coding rescue or AI-generated code cleanup.

Frequently asked questions

Start here

See where your operation is losing time.

Twenty minutes with an operator, not a salesperson. We'll name the one bottleneck costing you the most — and tell you whether it's worth fixing with software at all.

Book your free 20-minute consult→

20 minutes · video call · no preparation needed