Harden, refactor or rebuild an AI-built app?

Usually, harden it. A vibe-coded app from Lovable, Bolt.new or Replit tends to have a data model worth keeping and screens that work. It lacks access rules, server-side secrets and tests, and adding them costs a fraction of a second build. Refactor the one area that keeps breaking the rest. Rebuild only when the data model is wrong, tenancy cannot be retrofitted, or nobody can hire for the stack.

Hardening an AI-built app means keeping its code and behaviour while closing the gaps that fail under real users: access rules, secrets, validation, backups, tests and monitoring. Refactoring rewrites one part behind a boundary. Rebuilding starts again, keeping only the data and what you learned.

The decision in one table

The durations below are our own where we have a basis for them. A rebuild is priced like any other new product, because that is what it is.

Why most vibe-coded apps get hardened

What a founder has proved with real users is two things: the flows people will use, and roughly the shape of the data behind them. Both usually survive an audit intact. What does not survive is everything nobody asked the builder for: the database rules, the checks on the server, a backup somebody has restored. Those are additions to the code, and none is a reason to throw it away.

The findings are also predictable, which keeps hardening bounded. Public scans of AI-built apps keep turning up the same short list, and the checks we run first on an AI-built app are ordered by how much each one hurts. Most of them are closed where they sit: a policy written, a key rotated and moved behind a server function, a test added for the refund case.

A rebuild has to beat that. It costs more and takes longer, and it throws away the one thing the first version proved: that somebody wanted it. Ownership is no reason to rebuild either. The standard terms of Lovable, Bolt.new and Replit give you the rights in what their AI produced, subject to anyone else's, though none of them indemnifies you for it (all three checked in September 2026).

What forces a rebuild?

Three conditions justify one, each with a test you can run before paying anyone.

The first is a data model not worth keeping. Ask someone to draw the data on one page: what each table holds, who owns each row, which facts live in exactly one place. If the drawing needs an asterisk everywhere (the same fact stored three ways and disagreeing, rows with no owner, relationships hidden inside text fields), the model is the problem. New screens on top of it will not fix it.

The second is tenancy that cannot be retrofitted. An app built for one company and now sold to many needs the customer's identity in every table, every query, every cached value, every stored file and every background job. We put it in place before anything else on the platforms we build, because adding it later means revisiting every read the system makes. Past a certain size, retrofitting costs more than starting again with it built in.

The third is a stack nobody can hire for. If the app runs on something you cannot export, or on a combination only the original builder understood, the platform is the risk. Key-person risk usually means a person. Here it means a stack no second engineer can pick up.

Ugly code is not on the list, and neither is a framework your next hire dislikes. Nor does it count that an AI wrote it.

Refactor: one area, behind a boundary that holds

Generated code tends to accumulate copies and rarely consolidates them. In a June 2026 report covering 623 million code changes, GitClear found the refactoring share down to 3.8% from 21% in 2022. It also found copy-pasted code up from 9.4% to 15.7% over the same years (GitClear, 2026). GitClear sells code analytics, and the trend coincides with AI adoption without proving it caused it. The pattern is still familiar to anyone reading a generated codebase: the same rule written five slightly different ways.

A good refactor makes the mistake impossible to repeat. On a healthcare platform we build, a single delete method took its three identifiers in a different order from every other method, and the only protection against a mix-up was people remembering. We wrapped each identifier in its own type, so passing one where another belonged stopped compiling, then put the parameters in the same order everywhere, since the wrong order no longer compiled either. The change reached every model, every cache and every endpoint that handled those identifiers, and nothing was rebuilt.

When a component is past saving, rebuild the component rather than the app, behind an interface that does not move. On a client marketplace we have rewritten the customer-facing assistant twice, each time behind a request and response shape that never changed. The screens, the gateway and the back end that talk to it needed no changes either time, so each rewrite stayed inside one service, running beside the old one until the switch.

How we decide in the first week

We read before we change anything. The first test is whether the app builds from a clean checkout, the same bar a diligence reviewer applies in the first hour. Then we run the audit checks in their order, draw the data model on one page and count every place money moves.

What comes out is a written recommendation to harden, refactor or rebuild, with the cost of each. It also says what to do first, which is nearly always the access rules and the keys, because those are the findings that let one customer see another's data. Our AI-built app audit takes about a week and ends in that document.

If a funding round is coming, the order changes slightly. Investors read provenance and restore evidence early, so those move up, and a pre-raise plan ordered by what diligence weighs sets out the sequence. Settle who builds the next version at the same time, and ask every supplier for a specification sample, review records and tests that fail when a feature breaks.

Rebuilding with AI does not reset the clock

A rebuild is tempting because generating code is cheap now. The evidence on what cheap generation produces is less flattering. Carnegie Mellon researchers matched 806 open-source projects that adopted a popular AI code editor against similar projects that did not. Adoption brought a spike in output that was gone within two months. The rise in static analysis warnings, about 30%, and in code complexity, about 40%, did not go away (He et al., 2026). Open-source projects often review more lightly than commercial teams, so read it as a warning rather than a forecast.

A second version generated the same way as the first repeats the first one's problems, only later, because the quiet failures of coding agents are still waiting on the second. What changes the outcome is the process around the generation: a written specification, a person reviewing every change, and tests that fail when behaviour breaks. Put that process around the app you already have, and hardening it is usually the cheaper route.

We expect that line to move. Rebuilding a small app from a good specification is getting easier, and one day it may beat hardening for the smallest apps. It has not yet, because the costly parts of a rebuild are the migration, the cut-over and agreeing what the thing should do, and AI has made none of those cheap.

What founders ask next

Should we rebuild our Lovable app before raising money?

Not by default. Investors price risk they can see: access rules, provenance, tests, restore evidence and who can maintain the code. A hardened app whose history an investor can read usually does better than a fresh rewrite nobody has run in production. Rebuild first only if one of the three conditions applies, and start early.

Can we harden the app and keep using the builder?

You can, as long as one rule holds. Anything security-relevant lives where regeneration cannot overwrite it: database policies, server-side functions, and a regression test for each fix. Treat the builder as a tool for screens from then on, and review what it changes the way you would review any other contributor.

How long does hardening take?

Weeks for most apps, and the audit sets the number, because it depends on how many tables, roles and payment flows need rules and tests. A single workflow with one payment path sits at the short end, and several user types with marketplace money at the long end.

Will we lose data in a rebuild?

Not if the migration is its own project, mapped field by field, rehearsed on a copy, checked with row counts and spot checks, and given a cut-over date and a way back. The failures worth worrying about in a rebuild usually happen at the cut-over, not in the code.