What we find in apps built with AI

An app gets built in six weekends by one person who is not a developer. It works. People use it. Money moves through it. Then it reaches the point where somebody needs to take it over, and we get a call.

We have read several of these now. The findings are remarkably consistent, which is worth writing down, because if you built one you can check for these yourself in an afternoon.

The gap is not quality, it is time

The code is usually fine. Variable names are sensible, functions are short, the structure is often cleaner than code written by hand under deadline.

What is missing is everything that only matters later. An AI coding tool optimizes for the thing in front of it: make this screen work, make this button save. It is extremely good at that. Nobody asked it what happens on day four hundred, when a customer disputes an invoice and you need to know who changed the price.

That is the gap. Not craft. Horizon.

The eight

**Permissions checked in the browser.** The most common and the most serious. The interface hides the buttons you should not see, and the endpoint behind them checks nothing. Anyone who opens developer tools has the admin API. We have confirmed this from a signed-out browser in under ten minutes more than once.

**Database keys shipped to the client.** Modern database platforms issue a public key constrained by access rules and a secret key that bypasses them. When the public key stops working, swapping in the secret one makes the error disappear immediately. It also puts a credential with unrestricted access into a file every visitor downloads.

**No backups.** Free tiers generally do not include them, and nothing in the interface points this out. The app has one copy of every record it has ever held.

**Schema edited by hand.** Changes get made in a console, one at a time, over months. There is no record of how the database reached its current shape and no way to recreate it. Staging and production drift apart quietly.

**The same rule written five times.** Pricing, tax, discount logic. It appears in the form, the preview, the PDF, the export and a scheduled job, because each was built in its own conversation. They start identical. They do not stay identical, and the differences surface as invoices that do not match.

**No tests and no CI.** Every change is verified by hand, which works while one person holds the whole thing in their head and stops working the moment they do not.

**Nothing watching.** No error tracking, no uptime check. Failures are discovered when a user telephones, which means the quiet failures are never discovered at all.

**Deploys from one laptop.** Often with credentials that exist nowhere else. This is a business continuity problem wearing a technical costume.

Why these and not others

Every item on that list shares a property: the app works perfectly without it. You cannot tell from using the software whether any of them are true. They are invisible until the day they are the only thing that matters.

That is also why they do not get built. The tool had no reason to raise them, and the person building had no reason to ask.

The absence of a backup looks exactly like a working backup, right up until you need one.

What we do about it

Not a rewrite. The domain model in these apps is usually correct, and that is the genuinely hard part. Someone who does the job every day designed the screens, and the result is frequently better than the commercial product it replaced.

The repair is structural and smaller than it sounds. Most of the serious findings have one root: there is no server between the user and the database. Put one there, move the queries behind it, add a single authorization check, and three criticals close together. The screens do not change. Staff notice nothing.

Then backups, with a restore actually rehearsed. Then tests over the paths that touch money, and a pipeline so somebody other than the original author can ship a fix.

If you built one

Three questions, in order:

• If you sign out and call your own API directly, what comes back?
• Where is last night's backup, and when did anyone last restore it?
• If you were unavailable for two weeks, who could deploy a fix?

If the answers are uncomfortable, that is not a verdict on what you built. Getting a working product in front of real users is the part most projects never reach. The rest is a known list of work, and it is shorter than the thing you already did.