Is your vibe-coded app production ready? A 12-check scorecard

A vibe coded app production ready scorecard is how you decide, in writing, whether an app built with Lovable, Bolt, Cursor, Replit or v0 is safe to put in front of real customers. It is not a marketing checklist. It is twelve pass-or-fail checks, a simple score, and a clear launch gate so you stop guessing from a pretty preview.

This guide is the score-and-gate version of that question. If you want a senior engineer to walk the same list with you, that is what our vibe-coded app production ready review is for. You can also start with the free self-check and come back here to score the gaps.

How this scorecard differs from a general production list

We already publish a broader list of production checks for AI-built apps. That post is a narrative pass: what usually breaks, and why. This one is different on purpose:

• Every check is Pass, Fail, or Not sure — no soft language.
• You end with a number out of 12 and a launch gate (ship / fix first / stop).
• The focus is the buyer-intent question "is my vibe coded app production ready?" not a tutorial on one vendor.
• You get an owner-signed sheet you can keep next to the deploy button.

Use the narrative post when you are learning. Use this scorecard when you are about to invite paying users.

Before you start

Have these open:

1. Your live (or staging) URL on your real domain, not only the builder preview. 2. Your database dashboard (Supabase or the builder's built-in backend). 3. Two browsers or one normal window plus one private window. 4. Access to your host's usage and environment settings (Vercel, the builder's hosting panel, or both). 5. A blank note titled Launch score — [date] with twelve numbered rows.

Give yourself two to three hours the first time. Re-scoring after fixes usually takes under an hour.

The 12-check vibe coded app production ready scorecard

Score each check: Pass = 1, Fail = 0, Not sure = 0. Not sure counts as Fail for the launch gate. Honesty matters more than a high score.

Gate A — Strangers and data (checks 1–4)

1. A logged-out stranger cannot read private tables.

Open your app logged out. In the browser network panel, watch requests to your database API (often a rest/v1 or similar path). Or call the public API with only the publishable / anon key. If orders, messages, profiles or invoices come back without a login, Fail.

Why it fails so often: AI builders create tables fast; Row Level Security (RLS) is easy to leave off or leave as "allow all". Supabase's Security Advisor flags rls_disabled_in_public for this class of mistake.

2. User B cannot open User A's private record by changing an ID.

Sign up as A and as B. As A, open a private item and copy the URL or ID. Paste it into B's session. If B sees A's data, Fail. This is the classic insecure direct object reference pattern; OWASP still lists broken access control as a top risk.

3. File storage is not a public dump.

If users upload invoices, contracts or ID photos, open the storage rules. A public bucket that lists every object is a Fail for private files. Prefer private buckets and short-lived signed URLs. We walk a stranger-style storage check in is my Supabase leaking?.

4. Roles cannot be self-assigned from the browser.

If you have is_admin, role, or plan fields, confirm the client cannot set them on signup or profile update. Policies that trust user-editable metadata are a Fail. Store privileged roles in a table only server code can write.

Gate B — Secrets and server trust (checks 5–7)

5. No secret keys in the built JavaScript.

On the live site, open developer tools, search the loaded scripts for service_role, sb_secret, sk_live, sk-, and SECRET. Anything found is public. Fail, then rotate. Details live in OpenAI API key leaked? Secrets in the browser.

6. Every privileged server function checks who is calling.

Edge Functions and API routes are public URLs. Calling them outside your UI should still require a valid user (and the right role for admin actions). If a function trusts a body field like "isAdmin": true, Fail.

7. Paid status comes from a verified payment event, not a `/success` page.

Anyone can type /success. Unlock paid features only after your server verifies a webhook signature from the payment provider. If the app marks orders paid on page load, Fail.

Gate C — Launch plumbing (checks 8–10)

8. Auth redirects and cookies work on the real domain.

Complete signup, login, logout, password reset and OAuth (if you use it) on the production host. Preview hosts in redirect allow-lists are a Fail once you are live. After logout, Back + refresh must not revive a private page.

9. Environment variables match the environment.

Production must use production database, payment and email keys. A staging Stripe key or a preview database URL in production is a Fail. Confirm which project each key belongs to in the provider dashboards, not only in the builder UI.

10. You have a backup you have actually restored once.

A backup job that has never been restored is a Fail for launch. Restore into a throwaway project or branch and confirm the data you care about is there. Note the time it took.

Gate D — Cost and survival (checks 11–12)

11. Usage alerts and a spend ceiling exist on the host and the database.

AI-built apps often discover cost after a bot scrapes an open endpoint or a chatty page hammers the API. Confirm you have an alert and a hard or soft ceiling on Vercel (or your host) and on Supabase. Our Vercel bill shock post covers the noisy lines.

12. You know how to freeze the blast radius.

Write down, in one screen: how to rotate the database keys, how to disable public signups, how to roll back the last deploy, and who can do each step. If that page does not exist, Fail. Production ready means you can stop a bleed without waiting for the original prompt history.

How to score the launch gate

Add the twelve Pass marks.

• 11–12 Pass, zero Fail in Gate A or B: you may invite a small set of real users. Fix any remaining Fail this week.
• 9–10 Pass, no Fail in checks 1–7: soft launch only (friends, waitlist). Do not take card payments yet.
• Any Fail in checks 1–7, or score under 9: stop. Fix before marketing. These are the checks that leak data, skip payment, or expose secrets.
• Three or more Not sure: treat as a Fail on the gate. Not sure usually means nobody owns the system yet — common after a week of vibe coding, and a good reason for an outside review.

Re-score after every change to auth, roles, payments or schema. The number is only useful if it is current.

A one-page owner sheet (copy this)

Copy into your notes:

1. Logged-out private data: Pass / Fail / Not sure 2. User B ID swap: Pass / Fail / Not sure 3. Storage rules: Pass / Fail / Not sure 4. Roles not self-assigned: Pass / Fail / Not sure 5. No secrets in JS: Pass / Fail / Not sure 6. Server checks caller: Pass / Fail / Not sure 7. Paid via verified webhook: Pass / Fail / Not sure 8. Auth on real domain: Pass / Fail / Not sure 9. Env keys match env: Pass / Fail / Not sure 10. Backup restored once: Pass / Fail / Not sure 11. Alerts + spend ceiling: Pass / Fail / Not sure 12. Blast-radius runbook: Pass / Fail / Not sure

Score: __ / 12. Gate decision: ship / soft launch / stop. Owner: ____. Date: ____.

Sign it. The signature is the point. Preview demos do not need signatures. Production does.

Practical takeaways

• "Looks done in preview" is not a launch criterion. A scored gate is.
• Gate A and Gate B Failures block payments and marketing. Everything else can follow in days, not months.
• Not sure equals Fail for the gate. Find out, then re-score.
• Link this sheet to your deploy checklist so it cannot be skipped on launch day.
• Pair the scorecard with the free self-check when you want a second quick read.

FAQ

Is a vibe coded app production ready after the builder says it deployed?

Deployment means the files are on a host. Production ready means strangers cannot read private data, secrets are not in the browser, payments are verified on the server, and you can recover from a bad day. Those are separate questions.

How is this different from Lovable's or Bolt's built-in scans?

Vendor scans catch many configuration and dependency issues. They do not know your business rules, and they do not score a launch gate for you. Run their scans, then run this scorecard on the live URL.

Do I need this if I only have beta users?

Yes, if beta users enter real personal data or payments. A small audience does not make an open table private.

Can I re-use this scorecard for every release?

Yes. Re-run Gates A and B after schema, auth or payment changes. Re-run the full twelve before a marketing push or a price change.

---

Want a senior pass against the same twelve checks? Our vibe-coded app production ready review walks your Lovable, Bolt, Cursor or Replit app and returns a plain-English fix order. Book a free technical assessment and we will tell you what blocks launch first.