Is Your AI-Built App Ready for Production? A 20-Point Checklist

AI app builders such as Lovable, Bolt, Replit, v0 and Cursor can take you from an idea to a working demo in days. That is a real achievement, and it is also where the risk starts. A demo has one user, test data and no consequences. A production app has strangers, personal data, payments and a reputation to protect.

This checklist covers the 20 things an engineer checks before real users arrive. It is written for founders and product owners, so each point explains why it matters and how to verify it without reading the whole codebase. If you cannot answer more than a few of these confidently, an AI app technical audit will tell you where you stand before launch day does.

How to use this checklist

Work through the five groups below and mark each point as verified (you or someone tested it), assumed (the builder probably did it) or unknown. Treat "assumed" the same as "unknown". AI tools produce code that looks complete, and the gaps tend to sit exactly where nobody tested.

1. Accounts and access

1. Sign-up, email verification and password reset work end to end. Create a brand-new account, verify it, reset the password, then try to reuse the old reset link. Reset links should expire and work only once.
2. Authorization is enforced on the server, not just hidden in the interface. A button that is hidden from regular users protects nothing if the underlying request still works. Log in as a basic user and call the admin endpoints directly. They should refuse.
3. Roles are stored where users cannot edit them. In some stacks, user profile metadata can be changed by the user. If "is_admin" lives there, any user can promote themselves. Roles belong in a protected table or in server-controlled claims.
4. Login and other sensitive endpoints are rate limited. Without limits, attackers can try thousands of passwords or one-time codes, and bots can fill your sign-up form.
5. Admin areas are protected and admin accounts use multi-factor authentication. One stolen admin password should not be enough to read every customer's data.

2. Data and privacy

6. Every table that holds user data has access rules. With Supabase this means Row Level Security. A table without it can be read by anyone who has your public API key. See our guide to the seven RLS mistakes AI-built apps make.
7. Tenant isolation is proven with two test accounts. Log in as customer A, copy a record ID, then try to open or edit it as customer B. Also try changing IDs in URLs and API calls. This is the single most valuable test for any multi-user product.
8. Database changes live in version-controlled migrations. If the schema only exists inside a builder's dashboard, you cannot recreate it, review it or roll it back. Remember that some changes, such as dropping a column, cannot be undone without a backup.
9. Backups are switched on, and a restore has been tested. A backup you have never restored is a hope, not a plan. Time how long a restore takes and write it down.
10. You know what personal data you store and how to delete it. List the fields, where they live (including logs and third-party tools) and what happens when a user asks to be removed.

3. Payments and subscriptions

11. Payment webhooks are signature-verified and idempotent. Otherwise anyone can fake a "payment succeeded" message, and duplicate deliveries can create duplicate records. Details in our guide to Stripe webhooks and subscriptions.
12. Paid access comes from subscription events, not from the thank-you page. The success page is only a browser redirect. People close tabs, and anyone can type the URL.
13. Test mode and live mode are fully separated, and failures are handled. Separate keys, products and webhook endpoints. Check what happens on a failed renewal, a cancellation, a refund and a plan change.

4. Secrets and integrations

14. No secrets in the frontend bundle or the Git history. Anything shipped to the browser is public. Search your built JavaScript and your repository for service keys and API tokens. Rotate anything that was ever exposed, because deleting the file does not delete the history.
15. Third-party keys have least privilege and spending limits. This matters a lot for AI features. An unrestricted language-model API key in a public app can run up a large bill in hours. Set usage caps and per-user limits.
16. File uploads and storage buckets are locked down. Check who can read each bucket, who can upload, and whether file type and size are limited. Public buckets are fine for public images and dangerous for invoices or IDs.

5. Deployment and operations

17. Staging and production are separate. Different databases, different keys, different domains. Testing against production data is how customers receive test emails.
18. Error monitoring and uptime alerts reach a person who will act. If the first you hear about an outage is a customer message, monitoring is missing.
19. Domain, HTTPS and email deliverability are set up properly. That includes SPF, DKIM and DMARC records, so verification and receipt emails do not land in spam.
20. There is a rollback plan and a named owner. Who can deploy? How do you go back to the last working version? Who is on call? After launch, someone also has to apply updates, which is what SaaS monthly maintenance covers.

What to do with your results

• Mostly verified, a few unknowns: test the unknowns yourself this week, then launch with monitoring in place.
• Several unknowns in groups 1 to 3: pause. Access, data and payments are where mistakes become incidents. A focused review of those areas is cheaper than a breach or a billing bug.
• Known failures: list them with steps to reproduce. That list is exactly what an engineer needs to scope a fix, and it is the starting point for our AI app repair and production launch work.

What a checklist cannot tell you

A checklist finds known categories of problems. It cannot judge whether your architecture will cope with growth, whether your business logic has subtle flaws, or whether an attacker could chain small weaknesses together. If you need a formal security assessment, see the difference in our comparison of technical audits, penetration tests and code reviews.

The good news is that most launch blockers in AI-built apps are fixable without a rewrite. The aim is to find them while the only person affected is you.