Should you fix your AI-built app, or rebuild it?
Fix it, in most cases. AI tools do the time-consuming parts well — screens, forms, layout, basic flows — and get a small, concentrated set of things wrong: authentication, configuration and data access. Rebuilding discards the good work to redo the bad. The exception is when ownership was never modelled in the data.
Part of the guide to shipping an app built with an AI coding tool.
Why rebuild is the default advice
Two reasons, and only one of them is about your app. The first is that reading somebody else's code is genuinely harder than writing your own. The second is that a rebuild is a larger invoice.
That does not make the advice wrong. It does mean you should ask what specifically cannot be fixed, and be sceptical of an answer that arrives before anyone has read the code.
What is worth keeping
More than people assume. The parts AI tools generate well are the parts that take longest to build by hand:
- Screens and layout, including the responsive behaviour.
- Forms and their validation.
- The basic flows between pages.
- The shape of your data, if it was thought through.
That is weeks of work in a normal project. Throwing it away to fix a permissions problem is a poor trade.
What is usually wrong
- Access rules on the database, missing or too permissive.
- Permission checks that live in the interface rather than on the server.
- Secrets in the front-end that should not be there.
- Configuration that only ever existed in the tool's preview.
- Error handling, which is generally absent rather than wrong.
Notice what these have in common: they are concentrated, they are well understood, and none of them requires touching the interface.
The one case where rebuild is right
If ownership was never represented in the data, you are not patching anything. A permission rule needs something to check — a column recording which user a record belongs to. If no such column exists anywhere, every table has to change, and everything that reads those tables changes with it.
That is a rebuild of the foundation, even if the interface survives on top of it. It is worth finding out before you start rather than halfway through, which is the entire argument for having someone look before quoting.
A quick proxy: can you point at the thing in your data that says who owns each record? If not, assume the larger job.
A decision table
| Situation | Fix or rebuild | Why |
|---|---|---|
| No access rules, sensible tables | Fix | Adding policies is bounded, well-understood work |
| Secrets in the front-end | Fix | Rotate and move server-side; nothing structural |
| Will not deploy | Fix | Almost always configuration |
| Slow past a handful of users | Fix | Indexes and query shape |
| No ownership anywhere in the data | Rebuild the data layer | Nothing for a rule to check |
| You have outgrown what it does | Rebuild deliberately | A product decision, not a technical one |
The middle option nobody mentions
You can also fix what is dangerous now and rebuild later, on purpose, when you know more about what the product needs to be. Making an app safe to put in front of users is a much smaller job than making it perfect, and it buys you the time to learn whether the thing is worth perfecting.
Abhinav Chaudhary
Co-founder — UX/UI and frontend. Builds the part people actually touch. On a rescue job that usually means the login flow, the error states an AI tool never generated, and the screens that break the moment someone does something unexpected.
Want someone to look at yours?
Send us the repo or the live URL. You get a written list of what is broken, what each fix costs and what can wait — back within 24 hours, and yours to keep either way.
Get a $99 audit