The launch-ready checklist for AI-built SaaS: 24 checks before real users arrive

AI app builders are very good at the part users see. They are much less reliable at the parts users only notice when something breaks: who can read the database, where the keys live, what happens under load, and what the bill looks like at a thousand customers. These are the 24 checks we run before an AI-built app takes real users and real money.

Work through it in order. Each section is roughly sorted by how much damage the gap can do.

Security: 8 checks

1. Every table with user data has Row Level Security on, with owner-based policies. On Supabase, the public key in your front end can query the database directly, so RLS is the lock. We wrote a full walkthrough: how to check RLS in ten minutes.
2. No secret keys in the front end. Search your built JavaScript for sk_live, sk-, sb_secret_, service_role and AKIA. Anything the browser downloads is public. Rotate any key you find, because it has already shipped.
3. Permission checks happen on the server, not just in the UI. Hiding an admin button is not access control. Every API route and database policy should check who is calling, not trust a userId or role sent from the browser.
4. Payment and auth webhooks verify their signatures. An unverified Stripe webhook lets anyone mark an order as paid.
5. Storage buckets with private files are private, and files are served through short-lived signed URLs.
6. Auth basics are switched on: email confirmation, sensible password rules, rate-limited login and reset, and redirect URLs restricted to your own domains.
7. Security headers are set: HTTPS everywhere with HSTS, a Content Security Policy, and X-Frame-Options or frame-ancestors.
8. Dependencies have no known critical vulnerabilities. Run npm audit or turn on Dependabot, and remove packages the AI added and nothing uses.

Reliability: 5 checks

9. Backups exist and you have restored one. A backup you have never restored is a hope, not a backup. Know your point-in-time recovery window.
10. Errors reach you before users do. Front-end and back-end errors go to a tracker such as Sentry, with alerts on new issues.
11. Uptime is monitored from outside, on the pages and endpoints that make money: sign-up, login, checkout.
12. Calls to third-party APIs have timeouts and retries. When an LLM provider or payment API slows down, your app should degrade, not hang.
13. Production and development are separate, with separate databases and keys. Testing a prompt should never touch live customer data.

Scaling: 5 checks

14. Columns you filter, join or sort on are indexed, including the ones your RLS policies check. Missing indexes are the most common reason an AI-built app slows down at a few thousand rows.
15. Every list query is paginated. A select * with no limit works in the demo and times out in month three.
16. No query runs inside a loop. Fetching each item's details one request at a time (the N+1 pattern) multiplies load with every row.
17. Slow work runs in the background. Emails, LLM calls, exports and image processing belong in a queue or background function, not in the request the user is waiting on.
18. Public endpoints are rate limited, especially sign-up, login, and anything that calls a paid API on the user's behalf.

Cost: 4 checks

19. Spend alerts are set on every metered service: cloud, database, LLM provider, email and storage. A runaway loop should cost you an alert, not a month's revenue.
20. LLM calls use the smallest model that does the job, and repeated prompts are cached. In our reviews this is usually the largest single saving.
21. Per-user limits exist on anything expensive. One free-tier user scripting your AI feature should not be able to run up your bill.
22. Images and files are resized and served through a CDN rather than straight from the database or origin at full size.

Code health: 2 checks

23. The code and database schema live in git, with migrations. You need to see what changed, and roll it back, when a prompt breaks something.
24. The money paths have tests, and the AI has standing rules. Sign-up, payment and the core feature get a few end-to-end tests, and your project instructions record the security rules so the next prompt does not quietly undo them.

What to do with the results

If you ticked everything, you are in better shape than most apps we see. If a few security items failed, fix those this week; they are usually small changes with a large effect. Scaling and cost items can be scheduled against real traffic.

If you would rather have someone else run the list, our free app review checks what anyone on the internet can already see, and the Launch-Ready Audit covers all 24 checks with a prioritised fix plan.