Is your AI-built app ready for real users?
Answer each check Yes, No or Not sure. The five critical checks decide the verdict: one No or Not sure means the app should not take real users or payments yet. Your answers stay in this browser.
Data and access
Anyone who opens the browser's developer tools can often read or change data that belongs to other people.
Access rules are on for every table
In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say allow read, write: if true.
No secret keys reach the browser
Open your live app, then DevTools, Sources, and search the loaded JavaScript for sb_secret_, sk_live_, sk-proj- and sk-ant-. Older Supabase keys are long tokens starting with eyJ: decode the middle part of each on your own machine, and if it contains "role":"service_role", your secret key is public. A publishable or anon key in the browser is expected.
One user cannot open another user's records
Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.
File storage is private where it should be
Upload a private file, copy its URL, and open it in a private window. If it loads, the bucket is public.
Admin actions are checked on the server
Hiding an admin button is not protection. Call the admin endpoint as a normal user and confirm it is refused.
Sign-in and accounts
Sign-in usually works on the happy path and fails on the second day: reset emails, expired sessions, bots.
Sign-up confirmation and password reset work end to end
Use a real inbox. Check that the link arrives, points to your live domain, and works once.
Signing out really ends the session
Sign out, press Back, and refresh. You should not see private pages or data.
Sign-in and sign-up are rate limited
Without limits, bots create thousands of accounts and run up your email and AI bills.
Logic and payments
The demo path works. Real customers take the other paths: failed cards, refunds, double clicks.
Paid accounts are unlocked by a verified payment webhook
Access should change only when your server receives a signed webhook from Stripe or your provider, not when the browser reaches a success page.
Prices and plans come from the server
If the price or plan ID is sent from the browser, someone can edit it. The server should look it up.
Input is validated on the server
Forms that only check input in the browser accept anything sent directly to the API.
Failed payments, cancellations and refunds are tested
Use your provider's test cards for declines and disputes, then check what the user sees and what access they keep.
Code you can maintain
Each new prompt fixes one thing and breaks another, because nobody, the AI included, knows how the parts fit.
The code lives in a Git repository you own
Connect GitHub or export the project. If the builder account is lost, the product should not be.
The flows that make money have tests
Sign-up, checkout and the core action. A few end-to-end tests catch most regressions from new prompts.
Dead code and duplicate components are removed
Search for components with near-identical names. Three versions of one button means three places to fix every bug.
Dependencies are current and audited
Run npm audit. Critical advisories in packages you ship should be fixed before launch.
Hosting and recovery
Many AI-built apps run on a preview link with no backups, no alerts and one database for testing and real users.
Database backups run automatically and a restore has been tested
Check what your database plan actually includes, then restore a backup into a test project once.
Testing and real users use separate databases
Experiments and AI agents should never run against production data.
Errors reach you before users do
Add error monitoring and uptime alerts. If you learn about outages from customers, this is missing.
Secrets live in the host's environment settings
Keys belong in environment variables on the server, not in the repository or in front-end code.
Speed and running costs
Fine with ten test users. Slow and expensive with a thousand real ones.
AI and paid API calls have per-user limits
Without a cap, one user or one bot loop can spend your monthly budget in an hour.
Database columns you filter on are indexed
Queries that scan whole tables are fast at 100 rows and slow at 100,000.
Key pages load fast on a phone
Run PageSpeed Insights on the home page and the main app screen, on mobile.
Images are resized and compressed
Uploaded photos served at full size are a common cause of slow pages.
Questions
How do I know if my AI-built app is ready for production?
It is ready when every critical check passes: access rules on every table, no secret keys in the browser, users kept apart from each other, payments confirmed by a server webhook, and backups you have restored at least once.
How long does this checklist take?
The five critical checks take an afternoon if you can open your database dashboard and your browser's developer tools. The full list takes longer, because some checks need a second test account and a test payment.
What if I can't answer a check?
Answer Not sure. A check you can't confirm counts as open, because the risk is the same.