# Production-Readiness Check for AI-Built Apps

Source: https://www.plutonapps.com/tools/production-readiness-check

Updated 2026-11-07.

**Is your AI-built app ready for real users?** The Plutonapps production-readiness check scores an app built with Lovable or any AI builder out of 100, in about three minutes. Answer 22–35 questions, depending on your app, on security, data, releases, monitoring, payments, privacy and ownership, and get an A–F grade, a score for each area and a fix plan that starts with the three risks to fix first. It is free: answer the questions to see your grade, your score for each area and the risks to fix first; sign up free for the whole fix plan, with a prompt for each risk, as a PDF too. Give us your app's address first and we scan the live app, including its search visibility and email setup, and skip the questions the scan answers. Your answers stay in this page unless you ask for the report by email.

## How the score works

The production-readiness check asks 22 to 35 fixed questions, depending on your builder and your app, across seven areas: security and access, data safety, releases and testing, running it live, payments, privacy and compliance, and ownership. Sections on payments, mobile store releases, Lovable Cloud and compliance appear only when they apply. Each answer earns a fixed weight, scaled to 100 over the questions asked, any critical gap caps the score at 49, and the result is an A–F grade, a score per area and a fix plan whose first three risks are the ones to fix first.

Every question has a fixed weight, and the weights add up to 100. Your answer earns all, part or none of it; “Not sure” earns nothing. A question that does not apply to your app is left out and the rest are scaled back to 100. Any critical gap caps the score at 49. The rules are the same in your browser and on our server, and there is no AI in the loop.

| Area | Questions | Weight |
| --- | --- | --- |
| Security and access | 5 | 25 |
| Data safety | 3 | 20 |
| Releases and testing | 3 | 15 |
| Running it live | 3 | 15 |
| Payments | 2 | 10 |
| Privacy and compliance | 2 | 10 |
| Ownership | 1 | 5 |

Some questions are asked only when they apply — payments wiring if you take payments, store review if you plan an App Store or Google Play release, Lovable Cloud if your Lovable app runs on it, and health data or EU users — and add their weight to these areas. A question you are not asked never counts for or against you.

Bands: 90 and above is production-ready, 75 to 89 nearly there, 50 to 74 needs work, below 50 not ready. What each term means is in our [glossary](https://www.plutonapps.com/resources/glossary). Grades follow the score: A is 90 and above, B 80 to 89, C 65 to 79, D 50 to 64, and F below 50, so a critical gap is always an F.

## The questions

### About your app

- Which tool did you build the app with?
- Where does your Lovable app's database live?
- Will the app be released on the App Store or Google Play?
- Does the app hold health data, or have users in the EU or UK?

### Security and access

- How do people sign in to your app?
- Is multi-factor authentication on for every account that can change production — Supabase, hosting, GitHub, Stripe, your domain?
- Is row-level security on for every table that holds user data, with policies you have tested as a second user?
- Where does your Supabase service-role (secret) key live?
- Where are your other secrets kept — Stripe secret key, email and AI API keys?
- Does the live app serve a secret key, a .env file or its Git folder to anyone who asks? (Answered by the scan of your live app)

### Data safety

- If a bad change wiped a table at 3pm, what could you restore?
- Have you restored a backup into a separate project to prove it works?
- How do database changes reach production?
- Do you keep your own regular export of the data in Lovable Cloud? (Asked because your app runs on Lovable Cloud)

### Releases and testing

- Is there a staging environment, with its own database, where changes are checked first?
- Do automated tests cover your core flows — sign-up, payment and the main thing your app does?
- How does code get to production?
- Does the mobile app do more than show your website inside a wrapper? (Asked because you plan an App Store or Google Play release)
- If the app unlocks paid digital features or content, is it set up for the stores' in-app purchase rules? (Asked because you plan an App Store or Google Play release)
- Can people delete their account from inside the app? (Asked because you plan an App Store or Google Play release)
- Is sign-in ready for store review: Sign in with Apple beside any Google or other social login, and a demo account for the reviewer? (Asked because you plan an App Store or Google Play release)

### Running it live

- If the app broke for users right now, how would you find out?
- Are sign-up, login and anything that sends email or calls a paid API (such as an AI model) rate-limited?
- If production went down tonight, is there a named person and a written plan?
- Does the live app force HTTPS, keep a valid certificate and send the basic security headers? (Answered by the scan of your live app)
- Does the live app load fast and stay steady for real users? (Answered by the scan of your live app)

### Payments

- How does your app take payments?
- Are incoming webhooks checked by signature, and safe to receive twice?
- Are your payment provider's test and live keys kept apart, with the live keys only in production? (Asked because you take payments)
- Is each user's plan or subscription status stored against their account, and changed only by the payment provider's events? (Asked because you take payments)
- What happens when a renewal payment fails? (Asked because you take payments)

### Privacy and compliance

- Do you have the GDPR basics: a privacy policy naming your providers, a data processing agreement with each, and a way to delete a user's data on request?
- Can you tell who changed what in your admin area, and when?
- Does every provider that touches health data — database, hosting, email, AI — have a signed business associate agreement (BAA) with you? (A flag to review, not legal advice: asked because of health data or EU and UK users)
- Do analytics and other non-essential cookies wait for consent, and do you know where each provider stores your users' data? (A flag to review, not legal advice: asked because of health data or EU and UK users)
- Does the live app publish a privacy policy that covers what GDPR asks it to say? (Answered by the scan of your live app)
- If the live app loads analytics or ad trackers, does it show a cookie consent banner? (Answered by the scan of your live app)

### Ownership

- Is the code in a Git repository you own, and could another team deploy it without the person who built it?
- If you had to move off Lovable Cloud, do you know what moving would involve? (Asked because your app runs on Lovable Cloud)
- Do you know your monthly active users, and the point at which you would move to infrastructure you own? (Asked because your app runs on Lovable Cloud)

### Search and AI visibility

- Can search engines and AI assistants read and index the live app? (Answered by the scan of your live app)

### Email

- Does the app's domain have the email records that keep its mail out of spam? (Answered by the scan of your live app)

## Questions about the check

### What does the production-readiness check measure?

22–35 questions across seven areas that decide whether an app is safe for real users: security and access, data safety, releases and testing, running it live, payments, privacy and compliance, and ownership. Each answer is scored against a fixed weight, and the areas add up to 100.

### How is the score calculated?

Every question carries a weight, and the weights add up to 100. Your answer earns all, part or none of that weight. "Not sure" earns nothing, because if you cannot say it is done the safe assumption is that it is not. A question that does not apply to your app, such as payments when you take none, is left out and the rest are scaled back to 100. A critical gap, such as a service-role key in the browser, caps the score at 49. The same rules run on our server, with no AI involved.

### What score counts as production-ready?

90 or more is production-ready, 75 to 89 is nearly there, 50 to 74 needs work before launch, and below 50 is not ready for real users. Any single critical gap holds an app below 50, whatever else is in place.

### Do you store my answers?

Not unless you ask for the emailed report. The score is worked out in your browser. If you ask for the report, we store your email, the name and app address you give, your answers, your score, whether you ticked the box for updates, the campaign tags in the link and the page that sent you (neither if your browser sends Do Not Track or Global Privacy Control), and a one-way hash of your IP address, for 24 months. We send the report once and tell our team. We only send you anything else if you tick the box. We visit your app's address only if you ask for the scan, and then only read what any browser can: its public pages, scripts, a few fixed files and its legal pages. The scan's findings are not stored, except as answers in a report you ask for.

### Is it only for apps built with Lovable?

No. It works for any app built with an AI app builder such as Lovable, Bolt, v0 or Replit, or built by hand. Some questions name Supabase because most AI-built apps run on it, but the same checks apply to any app with a database, sign-in and payments.

### What does the live scan check?

If you give us your app's address, we read what any visitor's browser can: the page, the scripts it loads, a fixed list of files such as /.env and /.git, its security headers and certificate, its privacy policy and terms, how search engines and AI crawlers see it, and the email records (SPF, DKIM, DMARC) of its domain. We look for secret keys in the code, exposed files, missing protections, trackers with no consent banner, and whether the privacy policy names what GDPR asks for. Questions the scan answers are skipped. We never sign in, submit a form, read your database or store what we find. The privacy check matches words, not meaning: it is a flag to review, not legal advice.

### What should I fix first?

Start with the three risks the check shows you. Critical gaps come first, then the answers that lost the most points. Each one links to a plain-English definition in our glossary. If you would rather have engineers fix them, that is what a Plutonapps plan does.

## Rather have engineers fix it for you?

You keep designing in Lovable. Plutonapps engineers make the real product secure, tested and ready for production, on a subscription. [See the plans](https://www.plutonapps.com/pricing)