Can an AI-built app handle real users and real data?

The question behind the question

People usually mean one of two things: will it fall over, or will it leak something.

Falling over is mostly an infrastructure question, and it is the easier of the two. Modest traffic on a modern managed platform is not difficult, and most tools in this category deploy to infrastructure that handles far more than a new product will see.

Leaking something is a code question, and it is where generated applications are genuinely weaker than they look — not because a model writes insecure code on purpose, but because the failure is silent. An app with a missing permission check works perfectly. It works for the attacker too.

What to check before real users arrive

Are permission checks on the server? The most common serious flaw in generated applications is a check that exists in the interface and not in the API behind it. The button is hidden; the endpoint is not. Anyone who can open a browser console can reach it.

Is the database yours? Find out whether you have a real connection string, whether you can back it up, and what happens to the data if you stop paying. This is not a hypothetical question — it determines whether the product is an asset or a rental.

Are there backups, and have you restored one? A backup you have never restored is a belief, not a backup.

What happens on bad input? Real users submit empty forms, paste emoji into number fields and double-click submit buttons. Generated code often handles the happy path beautifully.

Where do secrets live? API keys in client-side code are a classic generated-app failure, and they are visible to anyone who views source.

What verification does and does not cover

A verification chain proves the application is internally consistent, that its tests pass, that it builds under production settings and that it starts. That removes the entire class of "it was never run", which is a real and common failure.

It does not prove any of the five things above. A missing permission check typechecks perfectly. A secret in the wrong place builds cleanly. Verification is a floor.

What verification does buy you, indirectly, is attention. If you are not spending your time discovering that the app is broken, you have time to look at the parts that need judgement — which is the small set of files that touch auth, money and personal data.

Rollback matters more than people expect

The safest way to run a real application is to be able to undo instantly. If every build is a content-hashed artifact, reverting is a pointer change — fast, and incapable of half-applying.

One caveat, and any tool that glosses over it is being careless: rolling back code is not rolling back data. Lovable states this plainly in its own documentation — reverting "does not restore or roll back database data". Once real users have written real rows, code and data have separate histories, and you need a plan for both.

A reasonable threshold

Internal tools, booking pages, waitlists, small marketplaces, client portals — yes, with the checks above done properly.

Anything handling payment details, health information, or data whose exposure would be a regulatory event — get someone to read it. Not because it was AI-built, but because that is true of any software, and being AI-built removes exactly none of that obligation.

Where the ceiling actually is

The limit usually arrives as a bill or a support ticket rather than an outage. Managed platforms absorb far more traffic than a new product generates, so the first real constraints tend to be database size, a query that was fine with a hundred rows and is not fine with a hundred thousand, and the moment you need something the platform does not offer — a background job, a specific region, a compliance control.

None of those require abandoning the app. They require knowing, in advance, whether the code and the data can move. That is the same question as ownership and export, asked a year later and under more pressure, which is why it is worth answering on day one.