Is My AI App Production-Ready? 30-Point Audit

If you built your app in Lovable, Bolt, Cursor, Replit or v0, here is the hard part: the demo working is not the same as the app being safe to put real users on. This is the exact 30-point audit we run before we let any AI-built app go live. Score yourself honestly. One point per item, seven categories, 30 checks total. It takes about 20 minutes and tells you the truth: ready to launch, or sitting on gaps that bite the day real traffic shows up.

What “production-ready” really means

Production-ready is not “the happy path works in the demo.” It means the app holds up when real people who are not you start hitting it at the same time, some of them careless, a few of them hostile. In practice that is three things. One: the right people can do the right things, and nobody else can. Two: nothing sensitive leaks, not your keys, not one user’s data to another user, not your stack traces. Three: when something breaks, it fails safely and you find out, instead of quietly leaking data or losing money. The 30 checks below are just those three ideas broken into things you can actually verify in your own codebase.

The 30-point checklist

Seven categories, roughly four to five items each. One point for every item you can honestly say is true of your app today. Be strict. “I think so” counts as a no.

Authentication

• Every protected route checks auth on the server, not just by hiding a button or link in the UI.
• Passwords are hashed (bcrypt, argon2, or your auth provider) and never stored or logged in plain text.
• Sessions or tokens expire, and logging out actually invalidates the session server-side.
• Password reset and email verification flows exist and cannot be bypassed to take over an account.
• Admin or privileged accounts are a real role check, not a hardcoded email or a flag the client can set.

Secrets management

• No API keys, database URLs, or tokens are hardcoded in the source or committed to git history.
• Nothing sensitive is prefixed with NEXT_PUBLIC_ or VITE_, so secrets never ship in the browser bundle.
• Server-only keys (Stripe secret key, service-role keys, third-party API keys) live in server environment variables only.
• Any key that ever touched client code or a public repo has been rotated, not just moved.

Data access / row-level security

• Row-Level Security is enabled on every table that holds user data (Supabase, Postgres, or your equivalent).
• A logged-in user cannot read or edit another user’s records by changing an ID in the URL or request.
• The database is not reachable with a public anon key that grants full read or write access.
• Write and delete operations are authorized server-side, not trusted from the client.
• Backups exist and you have actually restored one at least once to confirm they work.

Input validation

• Every form, query parameter, and request body is validated on the server before it is used.
• User input that reaches SQL uses parameterized queries, never string concatenation.
• User-supplied content rendered to the page is escaped or sanitized to prevent cross-site scripting.
• File uploads check type, size, and storage location, and are not served back as executable.
• Webhooks (Stripe, third-party) verify signatures before trusting the payload.

Error handling and logging

• Stack traces, database errors, and raw exceptions are never returned to the client.
• Secrets, tokens, and full request bodies are never written to logs.
• The app has a global error handler so an unhandled exception does not take down the whole process or leak internals.
• You have monitoring or alerting (Sentry, logs, uptime checks) so you find out about failures before users tell you.

Payments

• The charge amount and currency are set and verified server-side, never trusted from the client.
• You confirm payment success from a verified webhook or server call before granting access or shipping value.
• You are not storing raw card numbers; payments go through Stripe, PayPal, or a compliant processor.
• Refunds, failed charges, and duplicate submissions are handled and cannot be used to get the product for free.

Infrastructure and deploy

• The app runs over HTTPS with valid certificates and no mixed-content warnings.
• Production, staging, and local use separate databases and separate credentials.
• Deploys are repeatable from source control, not hand-edited on a live server you cannot reproduce.
• Basic rate limiting protects auth, payment, and expensive endpoints from abuse.

How to score yourself

Add up your points out of 30. Here is how to read what you get.

Score	What it means
25 to 30	Genuinely close. Fix the remaining items and you can launch with confidence.
20 to 24	Launchable soon. The gaps are real but contained, mostly a focused week of hardening.
Under 20	You have launch-blockers. Going live now risks data leaks, account takeover, or losing money. Fix the access-control, secrets, and payment gaps before any real users.

Most apps we audit straight out of a vibe-coding tool land between 8 and 15 on this scale. That is not a knock on the tools, or on you. AI builders optimize for output that runs, not output that is safe, so the security and access-control layers are usually the parts that never got built in the first place. The good news: the gaps are predictable, and predictable means fixable. For the security half of the audit in more depth, see how to audit AI-generated code for security.

The 3 most common launch-blockers

Across every app we have audited, the same three gaps show up over and over. They map straight onto why AI-built apps fall over in production: Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code introduces a known security vulnerability, and models pick an insecure pattern about as often as a secure one.

• Row-level security is off. The tables exist, the app works, but every user can read every other user’s data by changing an ID. This is the single most common and most damaging gap we find.
• Secrets are in the client bundle. A Stripe key or service-role key got prefixed with NEXT_PUBLIC_ or VITE_ and is now sitting in the JavaScript anyone can open in their browser.
• Stack traces leak to users. An error returns the raw exception, which exposes file paths, query structure, and sometimes secrets, handing an attacker a map of your system.

Fixing your gaps

Work in severity order, not file order. Close the access-control and secrets gaps first, because those are the ones that leak data or money the day you launch, then move to input validation, error handling, and payments. If the audit turns up a handful of issues in otherwise sane code, fix them in place. That is usually a focused week of work. Rebuild the affected layer instead when most tables lack access controls, when the data model itself is unsafe, or when the same broken pattern is copied everywhere. If you would rather have someone make the fix-vs-rebuild call with you and run the repairs, that is exactly what our prototype-to-production process does. For the platform-specific version of this audit, see is your Lovable app production-ready.

Scored under 20? We’ll tell you exactly what to fix.

We do a free 15-minute build audit: you show us your AI-built app, we walk the same 30 checks live and tell you the specific gaps and what it takes to close them. No obligation, no pitch you didn’t ask for.

Book your free build audit