Is your AI-built app safe to launch? A 12-point checklist

AI app builders have changed what one person can ship in a weekend. A founder with no engineering background can now describe an app and get a working prototype with sign-up, a dashboard and a database.

The catch is that "working on my laptop" and "safe for paying customers" are very different bars. The problems that matter most are invisible in a demo: nobody notices that every user can read every other user's data until someone does.

Here is the checklist we run when we audit an AI-built app before launch. You can work through most of it yourself in an afternoon.

Security and data

1. No secret keys in the browser

Open your live site, press F12, and search the JavaScript files for words like sk_, secret, service_role or api_key. Anything that ships to the browser is public. Publishable keys (like Stripe's pk_ keys or Supabase's anon key) are designed to be public; secret keys never are.

If you find one, rotate it immediately in the provider's dashboard, then move the call that uses it to a server function.

2. Database access rules are switched on

This is the most common serious issue we find. If you use Supabase, every table needs Row Level Security enabled, with policies that limit each user to their own rows. Firebase has the equivalent in Security Rules. AI tools often create tables with rules that are wide open during development and never tighten them.

A quick test: log in as one user, copy a request from the browser's Network tab, change the ID to another user's record, and send it. If you get their data back, you have a problem.

3. Admin actions are checked on the server

Hiding the "Delete user" button from non-admins isn't security. Every sensitive action needs a server-side check of who is asking, because anyone can call your API directly.

4. User input is validated on the server

Forms that only validate in the browser can be bypassed. Check lengths, formats and allowed values on the server too, especially for anything that ends up in emails, prices or database queries.

Accounts and payments

5. Password reset and email verification actually work

Test the full flow with a real inbox: sign up, verify, log out, reset the password, log in again. Check the emails don't land in spam, and that reset links expire.

6. Payments are confirmed by webhook, not by the redirect

A common AI-generated pattern marks an order as paid when the user lands on the "success" page. Anyone can visit that URL. Payment status should only change when your server receives a verified webhook from Stripe, Razorpay or Cashfree.

7. Subscriptions handle the unhappy paths

What happens when a card fails, a customer cancels, or a refund is issued? Make sure access is updated in each case, not just when someone first pays.

Reliability and performance

8. You'll know when something breaks

Add error monitoring (Sentry or similar) and uptime checks before launch. Otherwise your first bug report will come from an annoyed customer, or not at all.

9. Backups exist, and you've tried restoring one

Most managed databases offer automatic backups, sometimes only on paid plans. Confirm they're on, and do one test restore into a separate project.

10. Pages stay fast with real data

Prototypes are tested with ten rows. Create a few thousand test records and check that lists, search and dashboards still load quickly. Missing database indexes and loading entire tables into the browser are the usual culprits.

Launch basics

11. Search engines and link previews can read your pages

Many AI-built apps render everything in the browser, so Google and LinkedIn see an empty page. For marketing pages and blog posts, use server rendering or pre-rendering, and set a title, description and share image for each page.

12. You have a privacy policy and terms that match what you collect

If you collect emails, use analytics or take payments, you need both, plus a cookie banner for visitors in the UK and EU.

When to get help

None of this means AI tools were the wrong choice. They got you to a real product far faster than starting from scratch, and most of what they built is worth keeping. The last 30% is usually a focused couple of weeks of engineering, not a rewrite.

If you'd like a second pair of eyes, our Launch-Ready Audit covers this checklist and more in five working days, with a written report and a fixed quote to fix what we find.