AI app builders make the demo path work in hours. I see it every week: a founder opens a Lovable, Base44, Bolt or Replit app, signs up, clicks through the main flow, and it works. The hard question comes after that. In the words of the standard we published: "What decides whether an app can carry a business is everything the demo never tested: who can read which records, what happens when a payment webhook fails, whether a secret key shipped to the browser, and whether the owner can run the app without the builder."
"Production-ready" gets used loosely, so we wrote it down. This post walks through what it means, one check from each area, and how to use the list before you launch or hire someone.
The definition in one sentence
Here is the definition the standard starts from:
"A production-ready app is one real customers and the business can rely on: it shows each person only their data, takes payments correctly, survives failures, and is owned by the business that runs it."
That turns into 32 checks in ten areas. The security checks are mapped to the OWASP Top 10:2025, and every check says how it is verified.
Ten areas, one check from each
I picked the check from each area that I find fails most often or matters most. The wording below is quoted from the standard.
1. Access to data (OWASP A01 Broken Access Control). The standard calls this "the most common serious failure in AI-built apps: rules that let one user read or change another user's records." PR-01 passes when "every table holding personal or business data has access rules for create, read, update and delete." On Supabase that means Row Level Security with a policy for each operation, not just one for reads.
2. Secrets and configuration. PR-05: "No secret API keys (for example a Supabase secret or service-role key, Stripe secret key) in code sent to the browser." A publishable key in the frontend is fine; a secret key there is not.
3. Sign-in (OWASP A07). PR-10: "Sign-up, email confirmation, password reset and social sign-in complete on the production domain, with redirect addresses configured." In the apps we check, this is often the one that breaks when an app moves from its preview URL to its own domain.
4. Payments (OWASP A08). PR-13: "Payment webhooks verify the provider's signature before acting." Its neighbour PR-14 matters just as much: "Each payment grants access or credit exactly once, even on retries or page refreshes."
5. Inputs, integrations and AI features. PR-19 is new territory for many apps: "Prompts cannot make an AI feature act beyond the signed-in user's permissions, and AI spend has a limit."
6. Dependencies (OWASP A03). PR-20: "A lockfile is committed, and every package the AI added exists and is the intended one." Before you trust a package an AI added, look it up in the registry and confirm it's the one you meant.
7. Reliability. PR-24 is short: "Backups exist, and a restore has been tested." A backup nobody has restored is a hope, not a backup.
8. Speed and search (Google Core Web Vitals). PR-25: "Largest Contentful Paint is 2.5 seconds or less on mobile." That threshold comes from Google's Core Web Vitals guidance. PR-27 covers the basics search engines and AI assistants need: "Each public page has its own title, description and canonical address; robots.txt and a sitemap exist; key content is in the HTML."
9. Store readiness. PR-29: "A privacy policy, in-app account deletion where accounts exist, explained permissions and real content, with no placeholder screens." The standard lists Apple's App Review Guidelines as its source for this area.
10. Ownership. The standard puts it plainly: "An app the business depends on must be one the business controls." PR-31: "Database, domain, hosting, payment and email accounts belong to the business, not to a freelancer."
The other 22 checks fill in each area: tested rules (PR-02), server-side role checks (PR-03), HTTPS and security headers (PR-06, PR-07), rate-limited sign-in (PR-12), reconciled payment records (PR-15), alerts when something fails (PR-23), and an exportable data path with a short runbook (PR-32), among others.
Why "pass or fail" wording matters
The part of the standard I care about most is this line: "Every check is specific enough to pass or fail, and every check names how it is verified, so two people checking the same app reach the same answer."
"Make it secure" can't be checked. "Payment webhooks verify the provider's signature before acting" can. Each check names one of four ways it is verified:
- Automatically by the free Launch Check, which reads your live app the way a browser sees it. That covers PR-05 to PR-09 (secrets, HTTPS, headers, exposed files, cookies) and PR-25 to PR-28 (speed, layout shift, findability, accessibility).
- By the free AI audit of the code, for checks that need the source: access rules, server-side role checks, webhook verification, input validation.
- By the App Store readiness check, for store billing (PR-16) and review readiness (PR-29).
- By an engineer, for things only a person can test: rules tried as another user and as a signed-out visitor (PR-02), sessions ending when they should (PR-11), a restore that actually works (PR-24), accounts in the company's name (PR-31).
That split is honest about what an automated tool can and can't tell you. A scanner can see a missing Content-Security-Policy header. It can't see whether your orders table lets user A read user B's rows. You need both kinds of check.
How to use it
The standard suggests four uses, and they match how I'd use it myself:
- Before launch: "run the free Launch Check for the automatic checks, then the free AI audit for the code checks."
- With a developer: "attach the check numbers to the scope as acceptance criteria." Instead of "fix the security", the scope says "PR-01, PR-03, PR-13 pass", and both sides know what done looks like.
- Comparing offers: "ask each provider which checks their work covers and how they prove it."
- After launch: "re-run the automatic checks after every publish; most regressions are a header, a key or a rule changed by a later prompt."
That last one is easy to skip. With AI builders, every new prompt can touch code you thought was finished. A rule that passed last week can fail after an unrelated change.
Where to start
If you have an app live today, start with the checks a machine can run in a minute, then work down the list. The full standard, with all 32 checks, the OWASP mapping and how each is verified, is here: The Production-Ready Standard for AI-built apps. It's free to use, cite and check against.
For the automatic checks, our free Launch Check runs them on your live app in about a minute, no sign-up.
I wrote this with AI assistance and reviewed it myself.
Top comments (0)