Your AI Built the App. Before Real Customers Use It, Check These Five Things

An app built with an AI tool can be genuinely good. Lovable, Replit, Bolt, v0, Cursor and Claude Code now produce working software in an afternoon, and for a prototype that you use yourself, that is all you need. The risk starts the day the app meets real customers, real payments or real data, because the AI optimized for "it works when I click through it", not for "it holds up when a stranger pokes at it". Independent scans in 2026 found that a large share of publicly deployed AI-built apps carried serious flaws: in one scan of 5,600 live apps, researchers counted more than 2,000 high-impact vulnerabilities and 400 exposed secrets. Most of them were not exotic. They were keys in the browser, databases anyone could read, and admin screens nobody locked.

This guide is the check a senior engineer runs before such an app goes live, written so that an owner can follow it and a developer can act on it. It is organized in the order an attacker would try things, and it does not ask you to stop using AI. The goal is the opposite: to make it safe to keep building fast.

Everything the browser downloads, anyone can read. That includes the JavaScript bundle the AI tool generated, and it is the first place to look for keys that should never be there.

Open your live site, then open the browser's developer tools and search the loaded scripts, or do it from a terminal:

# List the script files your home page loads, then search them for key patterns
curl -s https://yourapp.com | grep -oE 'src="[^"]+\.js"' | sed 's/src="//;s/"$//' > scripts.txt
while read s; do
  case "$s" in http*) u="$s";; *) u="https://yourapp.com$s";; esac
  curl -s "$u" | grep -oE '(sk_live_[A-Za-z0-9]{10,}|sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|service_role)' | sort -u
done < scripts.txt

What the patterns mean:

• sk_live_... is a Stripe secret key. With it, anyone can issue refunds or read your customers. It belongs only on a server.
• sk-... is usually an OpenAI or similar AI key. Exposed, it lets anyone run up your AI bill.
• AKIA... is an AWS access key.
• service_role usually means a Supabase service key: it bypasses every database rule you have.

A Supabase anon key or a Firebase web config in the browser is normal. Those are designed to be public, but only because the database rules behind them are supposed to do the protecting, which is the next section.

If you find a secret key, treat it as stolen, not just exposed. Create a new key, move it to your host's environment variables (Vercel, Netlify, Replit Secrets), deploy, and then revoke the old key in the provider's dashboard. Moving it without revoking leaves the old one working for whoever already copied it. Finally, check the repository history: a key that was ever committed is still in the history even after the file changed.

Most AI app builders put the data in a hosted database (Supabase and Firebase are the common ones) and talk to it straight from the browser. That design is fine, and only fine, when the database itself enforces who may read and write each row. When those rules are missing, the anon key in the browser is enough to read every table.

For Supabase, run this in the SQL editor:

-- Tables in the public schema without row-level security
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Every table this returns can be read and written by anyone holding your public key, through Supabase's API. Supabase's own Security Advisor in the dashboard flags the same problem. For each table, turn row-level security on and add policies that match how the app is meant to work, for example "a user reads only their own orders":

alter table public.orders enable row level security;

create policy "Users read their own orders"
on public.orders for select
using (auth.uid() = user_id);

Two things to watch. Turning RLS on with no policies blocks everything, so the app may break until the policies exist; test on a branch or a copy first. And a policy written using (true) switches the protection off again, which is a common AI-generated shortcut.

For Firebase, open the Firestore and Storage rules. Rules that read allow read, write: if true;, or the "test mode" rules with an expiry date, mean the data is open. Replace them with rules that check request.auth.uid against the document's owner.

Then check the server side. Every API route and server function the app exposes must check, on the server, who is asking and whether they may see that record. A frequent AI-built flaw is a route like /api/invoices?id=123 that returns invoice 123 to anyone who changes the number. Log in as one test user, copy a request, change the ID to another user's record, and see what comes back.

Finally, admin screens. An admin page hidden behind an unlinked URL is not protected. It needs a real role, stored in your database and checked on the server for every admin action.

This is the check owners skip and regret. AI tools make it easy to start a project from a personal account, and a year later the business depends on a repository, a database and a domain that belong to whoever clicked "sign up".

Make a short list and confirm each item is in the company's name, with at least two people who can get in:

• Code: the repository in a company GitHub organization, not a personal account. If the app lives only inside the AI builder, export it to a repository now and confirm the export actually builds.
• Hosting and database: the Vercel, Netlify, Replit or Supabase workspace owned by a company account, with billing on a company card.
• Domain: the registrar account in the company's name. Losing the domain is losing the business's address.
• AI and API keys: keys issued under company accounts, with spending limits set in each provider's dashboard.
• A second admin everywhere: one person leaving, or locking themselves out, should never lock the company out.

Then take the way out once: export your data (a database dump, a CSV of users and orders) and open the file. An export you have never opened is a hope, not an exit.

AI-built apps tend to handle the happy path well and the unhappy paths not at all. Three failures matter most.

Lost data. Find out what backups your database plan actually includes and how far back they go, then test a restore into a separate project. The moment to learn that backups were never on, or never restorable, should not be the day you need one. If the plan's backups are thin, add your own scheduled export to storage you control.

Silent errors. If something breaks at 2am, who finds out? Connect error tracking (your host's logs with alerts, or a tool such as Sentry) so a person is told when errors spike, rather than a customer emailing a week later.

Money. If the app takes payments, check three things in the code:

• The price is decided on the server, never taken from what the browser sends. A checkout that trusts a price field in the request lets anyone pay one cent.
• Payment webhooks are verified. With Stripe, that means building the event with the signature check, not trusting the raw request body:

// Stripe webhook: verify the signature before acting on the event
const event = stripe.webhooks.constructEvent(rawBody, request.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET);

• Webhooks are idempotent. Providers retry and send duplicates; record each event's ID and ignore one you have already processed, so a retried "payment succeeded" does not ship an order twice.

Two smaller ones while you are here: rate-limit public endpoints such as sign-up, login and anything that calls a paid AI API, so one script cannot run up your bill; and if the app uses an AI model with tools, make sure the model can never do more than the signed-in user is allowed to do.

An app that works on its own still has to fit the business: orders that reach the fulfilment system, customers that reach the CRM, invoices that reach accounting. For each record, decide which system is the source of truth, and make the connection one way where you can. Two systems that can both edit the same field will eventually disagree.

Then make it safe to keep building with AI, because you will. Three habits do most of the work:

• Tests on the paths that move money or customer data. Not a full test suite: a handful of checks that sign-up, checkout and the main data screens still behave. Ask the AI to write them, then read them.
• A review step before production. Every change, human or AI, goes through a pull request and a preview deployment, and someone looks at it before it ships. Most hosts make preview deployments automatic.
• Know what depends on the AI tool. If the builder's pricing or terms change, which parts of the app go with it? Code you have exported and can deploy yourself is yours; code that only runs inside the builder is rented.

At the end of this check you should be able to say, in one page: no secret keys in the browser and every exposed one revoked; every table protected by rules that match how the app works; every account, key and domain in the company's name with two admins; backups restored once, errors that reach a person, and payment flows that survive retries; and a way to keep changing the app without breaking the parts that matter.

If you can say all of that, launch. If some of it is unclear, that is normal for an app built in a weekend, and it is a short list to work through rather than a reason to start over. Most AI-built apps keep most of their code. The work is in the gaps the AI was never asked to think about.

If you would rather have someone go through it with you, the AI-Build Audit is this check, run by a senior engineer, ending in a signed report that lists what is exposed, what you own and what to fix first. Either way, the Field Kit for this guide has every check above as a list you can work through with your team.