Why AI-built apps break the moment you deploy them

Rescue work is a large share of what Foundreco does, and the same findings keep appearing. What follows is the honest list, roughly in the order of how often it turns up, with what each one actually costs to put right.

1. Row-level security was never switched on

This is the most common and by far the most serious. Tools that sit on Postgres — Supabase in particular — ship tables with row-level security disabled until someone enables it. In the preview that is invisible, because you are the only user and every query looks correct.

In production it means any logged-in user can read every other user's rows. Sometimes any visitor at all. The app looks completely normal from the front end; the data is simply readable to anyone who opens the network tab and repeats the request with a different id.

A close relative is the policy that exists but does nothing — a rule written as allow all during development and never tightened. It shows up as "RLS: enabled" on the dashboard, which is why founders tell me they already checked.

How to check it yourself in two minutes: open your app in a normal browser window, log in as one test user, then open a private window and try to load another user's record by changing the id in the URL. If you can see it, you have this problem.

2. Secrets ended up in the browser

The second most common security finding is not a database hole at all. It is configuration: keys committed into the repository, or imported into client-side code where any visitor can read them by viewing source.

Front-end frameworks only expose variables carrying a specific prefix, and AI-generated code adds that prefix freely because it makes the error go away. It does make the error go away. It also publishes the key.

The fix is rarely just rotating the key. Anything that was reachable with that key has to move behind a server route, which means some of the logic has to be rewritten rather than reconfigured.

3. The preview's environment never existed anywhere else

This is the one that produces the classic symptom: it works in the editor and breaks on my own domain. The preview runs with a session, a database URL, redirect URLs and auth callbacks that the tool set up for you. Your deployment inherits none of it.

Every one of those values has to be set explicitly in the new environment, and a generated app rarely documents which ones it depends on. So the failure arrives as a blank screen or a login loop with nothing useful in the console, and you are left guessing at a list you were never given.

4. Nothing handles failure

Generated code is written for the path where everything works. The network is up, the payment succeeds, the upload completes, the third-party API answers in time.

Production is mostly the other paths. Without error handling, a single failed request takes down the whole screen instead of showing a message, and because there is no logging you find out from a user rather than from your own monitoring. This is not a security problem, but it is the one that makes an app feel broken to the people using it.

5. The same code exists five times

Ask an AI builder for a feature and it writes that feature. Ask for a similar one and it writes it again from scratch rather than reusing what is already there. After a few weeks you have the same logic duplicated across the codebase with small differences between copies.

Nothing is technically wrong on day one. The cost lands later: fix a bug in one copy and it survives in the other four, and every new feature takes longer than the last. This is the single biggest factor in what a rescue costs, because it decides whether the fix is a patch or a rewrite of that area.

What this costs to put right

Rescue work at Foundreco starts at $1,500, quoted as one fixed price after a 72-hour written audit rather than billed hourly. What moves the number is mostly item 5 — how much of the codebase is duplicated — and whether authentication and payments have to be rebuilt rather than patched.

If the honest answer is that the codebase should be rebuilt rather than repaired, the audit says so and the audit fee comes off the rebuild. That happens, and it is better to hear it in week one than in month three.

The part worth saying plainly

None of this means AI builders are a mistake. They get you from nothing to something people can react to, faster and cheaper than any other route, and that is genuinely valuable. Foundreco uses AI heavily on every build for exactly that reason.

What they do not do is the last twenty per cent: authentication, payments, security, deployment, and the judgement about what should be built in the first place. That last twenty per cent is where the money has always been, and it is the part that decides whether you have a demo or a product.

Questions founders ask about this