Production readiness checklist for AI apps
Run this before real users arrive. Each check below is something we have seen go wrong in a working app's first month, and each says how you can test it yourself.
Updated October 24, 2026: Turned the how-to-use heading into a question with a short direct answer.
Before real users arrive, run these 24 checks across data, access, testing, recovery and support, top to bottom, because anything you cannot tick is not a small problem: it is the reason launches go wrong.
0 of 24 complete
Data
Access
Testing
Recovery
Support
An AI-built app is ready for paying users when users see only their own data, secrets stay on the server, sign-in, payment and core journeys are tested, yesterday's data can be restored and someone hears about errors before customers do. The 24 checks on this page cover those five areas, in the order they tend to hurt.
You can run most of them yourself in an afternoon, without reading code, and the free readiness check gives you a score to start from. The list is written for a founder whose app already works in Lovable, Bolt or a similar tool and is about to take real customers. It is the engineering side of going live. The business side, from Stripe live mode to a privacy policy, is in our launch checklist for US founders.
Which check matches the problem you are seeing?
Match what you saw to its checks: leaked data to Access 2 and 3, an exposed key to Access 4, a paid customer who was not upgraded to Testing 3 and Support 3, and a fix that breaks something else to Testing 4 and Recovery 3. Then work through the rest.
| What you saw | Checks to start with | Read next |
|---|---|---|
| Users can see each other's data | Access 2 and 3 | Lovable users see each other's data |
| A key or password showed up in the browser or in GitHub | Access 4 | Lovable API key exposed |
| The security scan passed but you are not sure it is enough | Access 1 to 5 | What Lovable's security scan checks |
| A customer paid but their account did not upgrade | Testing 3, Support 3 | Stripe paid but not upgraded |
| Google sign-in works for you but not for customers | Testing 1 | Google login not working |
| Every fix breaks something else | Testing 4, Recovery 3 | When a Lovable fix breaks something else |
| The published app shows a blank page | Recovery 3, Support 1 | Blank page after publishing |
In what order should you work through the checks?
Data and access come first because a mistake there leaks customer information, which no later fix can undo. Testing comes next because it stops new mistakes. Recovery and support decide how bad a bad day gets. If you cannot tick an item, write down why.
That note is the brief for whoever fixes it, whether that is you, a developer or us.
Sources
The checks rest on these pages, all checked on October 22, 2026.
- OWASP: Application Security Verification Standard 5.0.0, on enforcing authorization at a trusted service layer (8.3.1), keeping secrets out of source code (13.3.1), identifying sensitive data and how long it is kept (14.1.1 and 14.1.2) and logging security events with when, where, who and what (16.2.1 and 16.3) (owasp.org/www-project-application-security-verification-standard; github.com/OWASP/ASVS/tree/v5.0.0/5.0/en).
- OWASP Top 10:2025, A01 Broken Access Control, on access control only working in trusted server-side code, and denying by default (top10.owasp.org/2025/A01_2025-Broken_Access_Control).
- Supabase documentation: Row Level Security, on tables without RLS being readable and writable by any role with a grant, and no data being reachable through the API once RLS is on until you create policies (supabase.com/docs/guides/database/postgres/row-level-security).
- Supabase documentation: Custom Claims and Role-based Access Control, on keeping roles in their own table (supabase.com/docs/guides/database/postgres/custom-claims-and-role-based-access-control-rbac).
- Supabase documentation: Understanding API keys, on secret and service_role keys bypassing Row Level Security (supabase.com/docs/guides/api/api-keys).
- Supabase documentation: Database Migrations, on migrations as the way to track database changes over time (supabase.com/docs/guides/deployment/database-migrations).
- PostgreSQL documentation: Constraints and Indexes, on primary key, foreign key and check constraints, and on indexes for finding rows without scanning the whole table (postgresql.org/docs/current/ddl-constraints.html; postgresql.org/docs/current/indexes-intro.html).
- Stripe documentation: API keys, on live secret keys starting with sk_live_ (docs.stripe.com/keys).
- Stripe documentation: Testing, on sandboxes, test API keys and test card numbers (docs.stripe.com/testing).
- Supabase documentation: Database Backups, on which plans are backed up daily and how many days of backups each keeps (supabase.com/docs/guides/platform/backups).
- Lovable documentation: Revert and restore your project with version history, on reverting to an earlier version, the Published badge and a revert restoring code but not database data (docs.lovable.dev/features/projects/history).
- Sentry documentation: Breadcrumbs, on the trail of events recorded before an error (docs.sentry.io/product/issues/issue-details/breadcrumbs).
Common questions
How long does this production-readiness checklist take?
You can run most of the 24 checks yourself in an afternoon, without reading code. Anything you cannot tick, write down why: that note is the brief for whoever fixes it, whether that is you, a developer or us.
Which checks should I do first?
Data and access. A mistake there leaks customer information, which no later fix can undo. Turn on row-level security with explicit policies on every table, keep roles out of the profile a user can edit, and make sure no secret key is in the browser or the repository.
What happens if row-level security is on but a table has no policy?
Supabase's documentation says that once RLS is enabled, no data is reachable through the API with a publishable key until you create policies. The opposite mistake is worse: a table without RLS is readable and writable by any role with a grant on it.
How do I test payments without real money?
Use a Stripe sandbox with test API keys and Stripe's test card numbers, which move no funds. Then check that the customer's account actually upgraded, not only that the payment went through.
Does rolling back a Lovable app restore my data?
No. Lovable's documentation says a revert restores your project's code only and does not roll back database data. That is why the checklist asks for scheduled backups and a restore you have actually tried, as well as a way to roll back a release.
More on this: Production architecture & security · Lovable app not working in production? How to make it production-ready
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
