# Production readiness checklist for AI apps

Source: https://www.plutonapps.com/resources/production-readiness-checklist

Published 2026-09-18, updated 2026-10-24, sources checked 2026-10-22. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib).

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.

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](https://www.plutonapps.com/tools/production-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](https://www.plutonapps.com/resources/launch-checklist-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](https://www.plutonapps.com/resources/lovable-users-see-each-others-data) |
| A key or password showed up in the browser or in GitHub | Access 4 | [Lovable API key exposed](https://www.plutonapps.com/resources/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](https://www.plutonapps.com/resources/lovable-security-scan) |
| A customer paid but their account did not upgrade | Testing 3, Support 3 | [Stripe paid but not upgraded](https://www.plutonapps.com/resources/lovable-stripe-paid-not-upgraded) |
| Google sign-in works for you but not for customers | Testing 1 | [Google login not working](https://www.plutonapps.com/resources/lovable-google-login-not-working) |
| Every fix breaks something else | Testing 4, Recovery 3 | [When a Lovable fix breaks something else](https://www.plutonapps.com/resources/lovable-fix-breaks-something-else) |
| The published app shows a blank page | Recovery 3, Support 1 | [Blank page after publishing](https://www.plutonapps.com/resources/lovable-blank-page-after-publish) |

## 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.

> If you are [working with us](https://www.plutonapps.com/pricing), every item here is ours to hold. The list is public so you can see exactly what that means. If a check has already failed in your live app, our [vibe-coding rescue service](https://www.plutonapps.com/services/vibe-coding-rescue) starts by finding the real cause before changing anything.

## 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](https://owasp.org/www-project-application-security-verification-standard); [github.com/OWASP/ASVS/tree/v5.0.0/5.0/en](https://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](https://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](https://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](https://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](https://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](https://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](https://postgresql.org/docs/current/ddl-constraints.html); [postgresql.org/docs/current/indexes-intro.html](https://postgresql.org/docs/current/indexes-intro.html)).
- Stripe documentation: API keys, on live secret keys starting with sk_live_ ([docs.stripe.com/keys](https://docs.stripe.com/keys)).
- Stripe documentation: Testing, on sandboxes, test API keys and test card numbers ([docs.stripe.com/testing](https://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](https://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](https://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](https://docs.sentry.io/product/issues/issue-details/breadcrumbs)).

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.

## Data

- [ ] Every table has a primary key and explicit relationships: Ask your AI tool to list every table and how they connect. A table nothing points to is usually a leftover.
- [ ] Columns that are queried often are indexed: Slow list pages with a few hundred rows are the usual sign an index is missing.
- [ ] Constraints prevent impossible states: Negative quantities, end dates before start dates, duplicate memberships.
- [ ] Personal data is identified and its retention decided: Write down which tables hold names, emails, health or payment details, and how long you keep them. Your privacy policy has to match.
- [ ] Migrations are versioned and reversible: Each database change is saved as a file, so you can see what changed and rebuild the database from scratch.

## Access

- [ ] Roles are stored separately from user profiles: If a user can edit their own profile and the role lives in the same row, they can make themselves an admin.
- [ ] Every table has row-level security enabled with explicit policies: Enabled with no policy denies everything; no policy without enabling allows everything.
- [ ] Server routes verify the caller, not the client: Anything the browser sends can be changed. Prices, user IDs and roles must be checked again on the server.
- [ ] Secrets live in environment configuration, never in the code: Search your GitHub repository for 'sk_live', 'secret' and 'service_role'. Any hit outside an environment setting needs rotating.
- [ ] Admin actions are logged with who did them and when: When something changes that should not have, this log is how you find out who did it.

## Testing

- [ ] Sign-up and sign-in are covered end to end: Try it in a private window with a brand-new email and a Google account that is not yours.
- [ ] The single most valuable user journey is covered end to end: Pick the one journey that makes you money and run it after every change, by hand if there are no automated tests yet.
- [ ] Payment or billing paths are tested against the provider's sandbox: Use Stripe test mode and a test card, then check the account upgraded, not only that the payment went through.
- [ ] Tests run automatically before anything is released: Without this, every prompt that fixes one thing can quietly break another.
- [ ] The app has been used on a real phone, not just a resized window: Check sign-up, payment and the main screen on an iPhone and an Android phone.

## Recovery

- [ ] Backups run on a schedule you can state out loud: For example: every night, kept for 7 days. If you cannot say it, assume there are none.
- [ ] A restore has actually been performed at least once: Restore into a copy, not the live database. A backup nobody has restored is a hope, not a backup.
- [ ] A release can be rolled back without a code change: In Lovable, that means knowing how to go back to the last working version and republish it.
- [ ] You know what data would be lost in the worst case, in minutes: If the database died now, how much would customers lose? An hour of orders is a different conversation from a week.

## Support

- [ ] Uptime and error rates are monitored: A free uptime monitor pinging your home page and sign-in page is enough to start.
- [ ] Alerts reach a named person, not a shared inbox nobody reads
- [ ] Errors are captured with enough context to diagnose them: An error tool such as Sentry shows what the user was doing when it broke, so you are not guessing from a screenshot.
- [ ] Users have a way to report a problem and get an answer: A visible support email or chat, and a reply within one business day.
- [ ] Someone is responsible out of hours, and knows it: Even if it is you. Put it in writing so nobody assumes someone else is watching.

## Frequently asked 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.