What should you check before shipping an AI-generated app?

The principle: check what a machine cannot

A good pipeline already establishes that the code is consistent, that the tests pass, that it builds and that it starts. If your tool does that on every build, you can stop worrying about that class of problem entirely.

What no build can establish is whether the software does the right thing. That is the list below, ordered by how much damage each item causes when it is wrong.

1. Permission checks on the server

The most serious and most common flaw. Open the network tab, find the request that loads data you would not want a stranger to see, and try it as a logged-out user or a different account. If it returns data, the check exists only in the interface.

This one is worth doing before anything else, because it is the failure that turns into a headline rather than a bug report.

2. Where the secrets are

Search the client-side bundle for anything that looks like a key. API keys, service tokens and database URLs belong on the server. This is a five-minute check and a permanent problem if skipped.

3. What happens on bad input

Submit the form empty. Submit it twice quickly. Paste 5,000 characters into a name field. Enter a negative quantity. Generated code handles the happy path well and the unhappy paths inconsistently, and real users find the unhappy paths within a day.

4. Backups you have actually restored

Confirm the database is backed up, then restore one into a scratch environment. Until you have done that once, you have a setting, not a backup.

5. The money and the personal data

Read these files. Not all of them — these. Anything that calculates a price, applies a discount, charges a card, or stores something about a person. It is usually a handful of files, and being unable to read code is not a reason to skip it: paste them to someone who can.

6. Emails and anything that leaves the building

Whatever your app sends, send it to yourself first, including the failure cases. An email that sends twice, or contains a template placeholder, or goes to the wrong recipient, is the kind of error that is embarrassing in a way bugs usually are not.

7. What happens under a bit of load

Not a load test. Open the app in five tabs and click around. Most performance problems in generated apps are obvious ones — a query in a loop, an unbounded fetch — and they show up immediately.

8. A rollback you have rehearsed

Know how to go back to the previous version before you need to. If your tool makes every build an immutable version and rollback a pointer change, this is a button. If it rebuilds, find out how long that takes while nothing is on fire.

What you can safely leave

Copy, spacing, colours, the exact wording of a validation message, anything cosmetic, anything you can change in a minute once someone complains. Perfecting these before launch is the most common way to not launch.

The shortest version

Before you ship: nobody can read data they should not, no key is in the browser, bad input does not break anything, you have restored a backup once, and someone has read the code that touches money.

The rest is what a verification chain is for, and if your tool runs one on every build, it is already done.

The first week after launch

Shipping is not the end of the checklist, and the first week is where generated applications reveal what a build could not.

Watch for errors you are not being told about. Confirm that something, somewhere, records a failure when a request fails — an app with no error reporting is an app whose problems you learn about from users, late and badly described.

Check your data after a day of real use. Look at actual rows. People will have entered things you did not anticipate, and the shape of what arrived tells you what to fix next better than any speculation beforehand.

And resist the urge to make changes on a Friday. Instant rollback makes recovery cheap, not free — the cost is still your evening.