Somewhere around the third week of asking an AI tool to fix the login without breaking checkout, most founders have the same thought: what if we just start again, properly this time?
Sometimes that's right. Usually it isn't. A rebuild throws away everything the current app already gets right, and that's normally more than it feels like when you're frustrated. The question worth asking isn't "is this code messy?" It almost always is. The question is whether the mess sits on a sound foundation or is the foundation.
Signs it's worth fixing
The data makes sense. Open the database and look at the tables. If there's one customers table, one orders table, and orders point at customers, the app has a spine. Messy screens on top of a sane data model are cheap to clean up.
Sign-in comes from a provider. If accounts run through Supabase Auth, Clerk, Auth0 or similar, the hardest security problem is already someone else's. What's left is checking permissions, which is fixable work.
It's one app in one framework. One Next.js or React project, one database, one place it's deployed. Generated code can be untangled when there is one of everything.
The bugs cluster. If most of what breaks is in two or three areas, those areas get rewritten and the rest stays. That's a fix with a rewrite inside it, not a rebuild.
Signs it's worth rebuilding
The same thing exists three times. Three versions of the pricing logic, two user tables that half overlap, a feature that was rebuilt in a new file each time the tool lost track of the old one. Past a point, finding which copy is live costs more than writing one clean copy.
The data model fights the business. If the way records are stored doesn't match how the business actually works, every new feature fights it. Fixing that means migrating all the existing data anyway, which is most of a rebuild.
Rules live only in the browser. If prices, permissions and limits are all enforced in front-end code with nothing behind them on the server, the security fix means building the backend that was never there.
Nobody can run it. If the app can only be deployed from the tool that built it, and it can't be exported into a normal repository and started on another machine, you don't own it yet. Sometimes getting it out is easy. Sometimes it isn't, and that alone decides the question.
The middle path most apps end up on
In practice the answer is usually "keep the data and the sign-in, rewrite the worst two areas, add tests around everything else." It's less satisfying than a clean slate. It also ships in weeks rather than months, and your users never see a migration.
Whichever way it goes, make the decision once, in writing, based on what's actually in the code rather than how the last week felt. That's what our production review does: a written answer on fix versus rebuild, with the reasons and a fixed quote for whichever one wins.