Vibe Coded App to Production: The 2026 Launch Checklist

Legacies is a software and web studio from Romania, founded by Horia Stan and Alexandru Talnaci, and a growing part of our work is taking apps that founders built with Lovable, Bolt, v0, Replit or Cursor and making them safe to launch. This is the checklist we actually use.

Taking a vibe coded app to production means checking the parts the AI rarely gets right on its own: who can read and write which data, where your secrets live, how payments are confirmed, and what happens when something fails. Most prototypes need one to three weeks of focused work here, not a rewrite. Publishing a preview link is not the same as being in production.

Quick answer

• Lock down data first: enable row-level security on every table, write real policies and test them logged out.
• Move secrets server side: no secret keys in frontend code, rotate anything that was ever exposed.
• Verify payments on the server: grant paid access only from signed webhooks, never from a redirect page.
• Add the boring safety net: error tracking, backups, a staging environment, a few tests and spending limits.

Why a working prototype is not production yet

A prototype answers "does this do the thing?" Production answers "does it still do the right thing when 500 strangers, one bored attacker and a failed payment show up on the same day?"

If you want the background on what vibe coding is and where it breaks, start with what is vibe coding. Here we go straight to the work.

The production checklist

Go through these in order. The first three are where we find the most serious problems.

1. Authentication and authorization

Authentication is "who are you." Authorization is "what are you allowed to do." AI tools usually get the first one working, because a login screen is visible. The second one is where apps leak.

• Every API route and server action checks the session on the server, not only in the UI.
• A user cannot load or edit another user's record by changing an ID in the URL or request.
• Admin pages are protected on the server. Hiding a button is not protection.
• Password reset, email verification and session expiry actually work.
• Sign-up has rate limits or a captcha, so nobody can create 10,000 accounts.

2. Database rules (Supabase RLS and friends)

Most Lovable, Bolt and v0 apps use Supabase. Supabase exposes your database through an API that the browser calls directly, using a public key. That is fine, but only if Row Level Security (RLS) is enabled and correct on every table. The Supabase RLS guide is blunt about it: a table in an exposed schema without RLS is readable and writable by any role with a grant on it.

In 2025, researcher Matt Palmer found that 170 of 1,645 apps from Lovable's showcase had tables open this way (CVE-2025-48757). In February 2026, Wiz found the production database of Moltbook, an app its founder said he built without writing code, wide open because RLS was off. It exposed 1.5 million API tokens and 35,000 email addresses.

What to check:

• RLS is on for every table in the public schema, including ones the AI created later.
• Each table has separate policies for select, insert, update and delete.
• Policies use the logged-in user, for example:

alter table projects enable row level security;

create policy "Owners read their projects"
on projects for select
to authenticated
using ( (select auth.uid()) = owner_id );

• The service role key is used only in server code, never in the browser.
• Storage buckets with user files are private, with their own policies.
• You ran the Supabase Security Advisor in the dashboard and fixed what it flagged.

3. Secrets and environment variables

Search your frontend bundle for keys. Anything shipped to the browser is public, no matter how the variable is named.

• OpenAI, Anthropic, Stripe secret, Resend and similar keys live only on the server.
• In Next.js, only variables prefixed with NEXT_PUBLIC_ reach the browser. Check that none of those are secrets.
• .env files are not in the Git repository, and never were. If they were, rotate every key in them.
• Calls to paid AI APIs go through your server, with per-user limits, so nobody can run up your bill.

4. Payments

Payment bugs cost money directly, so we test them by trying to cheat.

• Paid access is granted only after a verified webhook from Stripe or your provider. A "success" redirect page can be opened by anyone.
• The webhook checks the signature. Stripe's webhook docs warn that without verification an attacker can send fake events to fulfill orders or grant access.
• Webhooks are idempotent. Stripe can send the same event twice.
• Prices come from the server or the provider, never from a value the browser sends.
• Cancellations, failed renewals and refunds remove access correctly.

5. Error handling and input validation

• Every form is validated on the server, not only in the browser.
• Errors show a friendly message, not a stack trace with file paths.
• External calls (AI APIs, email, payments) have timeouts and a fallback.

6. Tests

You do not need 100% coverage. You need tests on the flows that make or lose money.

7. Hosting and environments

• A separate staging environment with its own database. Never let an agent work against production data. In July 2025, a Replit agent deleted the production database of a project SaaStr founder Jason Lemkin was building, during a declared code freeze.
• Daily database backups, and one restore you actually tested.
• A custom domain with HTTPS, and email sending set up with SPF, DKIM and DMARC so your emails do not land in spam.
• Check the plan terms. Vercel's pricing page says the free Hobby plan is for personal, non-commercial use, and Supabase pauses free projects after a week of inactivity.

8. Monitoring

• Error tracking, so you hear about bugs before users email you.
• Uptime checks on the home page and one key API route.
• Alerts on your AI provider and cloud spend.

9. Dependencies and updates

AI tools add packages freely. Some are outdated, some are not needed, and occasionally one does not exist and gets registered later by an attacker. Run an audit, remove what you do not use, and plan regular updates. We explain why in npm supply chain security and Next.js security patches are now a product maintenance task.

What production really costs per month

Builder subscriptions are only one line. These are typical starting prices from official pages at the time of writing.

For many small apps that lands somewhere around $50 to $150 a month before AI usage. AI features are the line that grows fastest, which is why per-user limits matter. For the full picture of build and running costs, see how much it costs to build an app in 2026.

Fix it, or rebuild it?

After reviewing a vibe coded app, we usually land in one of three places.

A rebuild is not a failure. The prototype proved people want the product and showed what to build. We review what the AI built, tell you plainly which bucket you are in, and then ship it with a fixed price.

When to do it yourself and when to bring in a team

Do it yourself if you are comfortable reading the code, the app holds no payments or sensitive data yet, and you can work through this checklist with your coding agent while checking every change. Many founders can, and the list above is meant to make that possible.

Bring in a team when real money or personal data is about to flow through the app, when you cannot tell whether a policy is correct, or when the AI keeps breaking one thing while fixing another. Our services page has fixed prices: web apps start at 3,499 lei (about EUR 665), and monthly maintenance is 499 lei (about EUR 95) for monitoring, updates and backups after launch. You can see what we have shipped on our projects page. Have a marketing site too? Our free website audit checks it in seconds. Security is your main worry? Read vibe coding security risks.

Frequently Asked Questions

How do I deploy a vibe coded app to production?

Start by securing the data layer: enable row-level security on every database table and test that logged-out users and other users cannot read private data. Then move every secret key to the server, verify payments through signed webhooks, add error tracking and backups, and deploy to a paid hosting plan with a staging environment. Publishing from the builder is only the last step.

Is a Lovable or Bolt app ready for production out of the box?

Usually not for an app with real users and payments. The builders now run security scans, and Lovable's docs describe a quick scan before each publish, but they also say automated scans cannot guarantee complete security. You still need to check authorization, database policies, secrets, payments and backups yourself or with someone who reads code.

What is Supabase RLS and why does it matter for vibe coded apps?

Row Level Security is a Postgres feature that decides which rows each user can read or change. Supabase apps call the database straight from the browser with a public key, so RLS is the main thing protecting your data. If it is off on a table, anyone with that public key can read or edit it, which is how several vibe coded apps leaked user data.

How much does it cost to run a vibe coded app in production?

For a small app, expect roughly $50 to $150 a month before AI usage: a paid database plan like Supabase Pro from $25, hosting like Vercel Pro at $20 per member, the builder subscription, a domain, and email and error tracking. AI API costs come on top and grow with users, so put per-user limits on any AI feature.

Should I rebuild my vibe coded app from scratch?

Not automatically. If the structure is reasonable, fixing security, adding tests and cleaning up the data model is faster and cheaper. A rebuild makes sense when every change breaks something else or the data model no longer fits the product. In that case the prototype still has value, because it defines exactly what the real app needs to do.