From Vibe-Coded Prototype to Production: The Launch Checklist

An app built with Cursor, Lovable, Bolt or Replit can be launched safely, but "it works" and "it's safe" look identical from the outside. Before real users arrive, check ten things: database access rules, secrets, authorisation, payments, input validation, error tracking, tests on the money paths, backups, deployment and handover. Most prototypes need fixing, not rewriting.

Disclosure: I run Ship It Live, which offers a fixed-price sprint for exactly this. Everything below works whether you hire us, someone else, or do it yourself.

Why does a vibe-coded app need a production pass?

Because AI tools are very good at making things work and much less reliable at making them safe. The failures that matter most are invisible in a demo.

Andrej Karpathy named the practice in February 2025, describing it as a style where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists" (Wikipedia, vibe coding). That's a great way to reach a prototype. It's a risky way to run a product, because production is mostly about the code you've forgotten exists.

The evidence is consistent:

• Veracode tested code from more than 100 large language models across Java, JavaScript, Python and C#. AI-generated code introduced risky security flaws in 45% of tests, and larger, newer models didn't do better (October 2025 update).
• A Stanford study found that developers using an AI assistant wrote significantly less secure code and were more likely to believe it was secure (Perry, Srivastava, Kumar and Boneh).
• In 2025, a researcher found 303 exposed endpoints across 170 apps built with Lovable, caused by missing database access rules. It was logged as CVE-2025-48757, with a CVSS score of 9.3 (critical).

None of this means AI-built apps are bad. It means the last step, the production pass, can't be skipped.

The 10-point launch checklist

Here's the whole list at a glance. Each item is explained below, with a quick check a non-developer can run.

#	Check	What goes wrong if you skip it
1	Database access rules	Anyone can read or change other users' data
2	Secrets out of the browser	Your admin keys are public
3	Authorisation, not just login	Users can do things they didn't pay for
4	Payments verified on the server	People get paid features for free
5	Input validation and rate limits	Spam sign-ups, abuse and surprise bills
6	Error tracking and logs	Users hit errors you never hear about
7	Tests on the money paths	Billing breaks silently
8	Backups and migrations	One bad change loses real data
9	A real deployment pipeline	Shipping is a risky manual ritual
10	Readable code and a handover	The next developer starts from zero

1. Are your database access rules actually on?

This is the most common serious flaw in AI-built apps. Many of them talk to the database directly from the browser, so the database itself must decide who can see which rows.

On Supabase, that's Row Level Security (RLS). The documentation is blunt: "Enable RLS on every table in an exposed schema", because a table without it "is readable and writable by any role with a grant on it". Turning RLS on isn't enough by itself, either. Every table needs policies that say exactly who can read, insert, update and delete each row.

Quick check: open your Supabase dashboard and look at every table. Each one should say RLS is enabled, and each user-owned table should have a policy that compares the row's owner with the signed-in user.

2. Are any secret keys in your front-end code?

A secret key in the browser is a public key. Anyone can open the developer tools and copy it.

Supabase's own guidance: "Never use a secret key in the browser or expose it to customers." The same goes for Stripe secret keys, OpenAI keys and any other API key that costs money or bypasses rules.

Quick check: open your live site, press F12, go to Sources, and search the code for service_role, sk_live, sk- and secret. Anything you find needs to move to the server and be rotated, because it's already been exposed.

3. Does your app check permission, or only identity?

Login answers "who are you?" Authorisation answers "are you allowed to do this?" AI-generated code often checks the first and assumes the second.

Here's a real example from Cafeity, an iOS app I make. Its subscriptions table had rules that only let users write their own row, which sounds safe. But "it's your row" isn't proof that you paid. Any signed-in user could have called the database directly and marked their own subscription as active. We fixed it by removing the app's right to write that table at all; only the server function that verifies Apple's signed purchase can write it now. The rules were on, and the hole was still there.

Quick check: for every action that unlocks money or data, ask "what stops a user from just sending this request themselves?" If the answer is "the button is hidden", it isn't protected.

4. Are payments verified on the server?

Never trust the browser to say a payment succeeded. Payment state should come from the payment provider, through a webhook or API call your server verifies.

Quick check: find where your app marks a user as paid. If that code runs in the browser, or on a server route that doesn't verify a signed event from Stripe (or your provider), fix it before launch.

5. Do you validate input and limit abuse?

Real users and bots will send things your prototype never saw: huge files, scripts in text fields, and thousands of sign-ups a minute. Veracode's report found that AI models failed to defend against cross-site scripting in 86% of relevant tests.

Quick check: confirm that forms are validated on the server, not only in the browser. Check that sign-up and any AI or email-sending endpoint have rate limits, and that file uploads have size and type limits.

6. Will you know when something breaks?

If your only error report is a user emailing you, most errors go unreported. Add an error tracker (such as Sentry) and uptime monitoring before launch, not after the first angry email.

Quick check: break something on purpose in staging and see whether you get an alert.

7. Are the money paths tested?

You don't need full test coverage to launch. You need tests around the paths that cost money if they break: sign-up, checkout, plan changes, failed payments and cancellations.

Quick check: ask "if Stripe sent a failed-payment event tonight, what would our app do?" If nobody knows, that path isn't tested.

8. Can you restore your data?

A backup you've never restored is a hope, not a backup. Database changes should also be written as migration files in your repository, so you can see and undo them, instead of being clicked into a dashboard.

Quick check: confirm automatic backups are on, then restore one into a test project once.

9. Is deploying a command or a ritual?

If deploying means one person running steps from memory, every release is a risk. A production app needs separate staging and production environments, and a pipeline that deploys the same way every time.

Quick check: could someone other than you deploy a fix tonight, from written steps?

10. Could another developer take over?

AI-generated codebases can grow fast and inconsistently. Before launch, remove dead code, write down how to run and deploy the app, and list every external service and where its keys live.

Quick check: hand the README to a developer you trust and ask how long it would take them to run the app locally.

Fix it or rebuild it?

Usually fix it. Most AI-built prototypes are structurally fine and specifically insecure. The work is access rules, auth, tests and deployment, not a rewrite.

A rebuild only makes sense when the core data model is wrong, or the code is so tangled that every fix breaks something else. Get a written audit before anyone quotes you either way, so the decision is based on what's actually there.

Get a production pass on your prototype

Our vibe coding to production sprint covers this whole checklist in 21 days, from a fixed $1,999. It starts with a three-day written audit that you keep either way. If you're still deciding what to build, start with what a SaaS MVP really costs.

Sources checked on 5 October 2026: Veracode, Stanford (arXiv 2211.03622), CVE-2025-48757, Supabase documentation and Wikipedia. Questions? Talk to the Ship It Live team.