Vibe Coding Production Apps: The Quality Bar Nobody Talks About

Vibe coding production apps works when the app clears a quality bar the prompt never mentioned: every table locked by Row Level Security, every failure showing the user something useful, every schema change in a migration file, and an alert that reaches you before a customer does. That bar is public. Supabase, Vercel, Next.js and Stripe each publish a production checklist, and this guide folds them into one pass you can run in about a week.

Built from the vendors' documentation, checked October 2026, not from a case study of our own app: Supabase's production checklist, API keys, Row Level Security, advisors, migrations and backups pages; Vercel's production checklist; the Next.js production guide; Stripe's go-live checklist; Lovable's security docs; and Veracode's Spring 2026 GenAI code security update.

The examples use Supabase, Next.js, Vercel and Stripe because it is a common stack for AI-built apps and the one our own guides use. The same seven questions apply to any stack. If vibe coding itself is new to you, start with our vibe coding guide; if you build with an agent in the terminal, the Claude Code complete guide explains the tools this page leans on.

Can you ship vibe coded apps?

Yes, on one condition: you verify what you did not write. The risk is not that AI-written code fails to run. It runs, which is why the demo looks finished. The risk is what it leaves out when nobody asked for it.

Read that number for what it is. Veracode tested isolated coding tasks built around four flaw types (SQL injection, cross-site scripting, log injection and weak encryption choices), not whole apps, and Veracode sells security tooling. The useful part is the trend: it reports security pass rates "essentially flat" regardless of model generation or release date. A newer model does not excuse the checks.

The quality bar for vibe coding production apps

Seven areas separate a prototype from something you can charge for. In each one the prototype default is reasonable for a demo and wrong for production, and in each one the vendor has already written down what "right" means.

Data access and auth: who can read what?

Start here, because this is the failure with the worst outcome: one user reading another user's data. A Supabase app ships its publishable key to every browser, and that is by design. Supabase's docs say the key is safe to expose and "only reaches what Row Level Security allows". So the key is not the lock. RLS is, and the docs put it bluntly: enable RLS on every table in an exposed schema.

alter table public.reports enable row level security;

That line is from Supabase's RLS guide. Once RLS is on and no policy exists, no data is accessible through the API with a publishable key, so the next step is a policy that says who may see which rows. The guide's example lets signed-in users read only their own:

create policy "Individuals can view their own todos."
on todos for select
to authenticated
using ( (select auth.uid()) = user_id );

You do not have to audit this by reading code. Open Advisors in the Supabase dashboard, or run supabase db advisors, and clear the errors first:

Then run the test no scanner replaces. Create two accounts, sign in as the second, and try to read and edit the first one's rows from the app and from the browser console. If that works, nothing else on this page matters yet.

Three more items from the vendor checklists close most of the remaining auth gaps:

• Turn on the sign-up protections. Supabase's checklist lists email confirmations, CAPTCHA on sign-up, sign-in and password reset, and a one-time-code expiry of 3,600 seconds or lower.
• Connect your own SMTP server. Without it, Supabase limits endpoints that send email to 2 emails per hour (checked October 2026). Your third sign-up in an hour gets no confirmation email.
• Check permissions inside every server action. The Next.js production guide says to verify authentication and authorization inside each action and not to rely on proxy, layout or page-level checks alone.

On keys: Supabase says it is deprecating the legacy anon and service_role keys by the end of 2026 in favour of publishable and secret keys, so generated code that still uses the old names needs a pass. Stripe's checklist says to rotate API keys before going live in case they were saved somewhere outside the codebase during development. For a vibe-coded app, "somewhere" includes every chat you pasted a key into.

Error states: what does the user see when it fails?

A prototype has one state: it worked. A product needs an answer for every way it does not. The Next.js docs split errors into two kinds, and the split is a useful checklist on its own.

• Expected errors are part of normal operation: a failed validation, a declined request. The docs say to return them as values and show them to the user, not to throw.
• Uncaught exceptions are bugs. They need custom error pages (error.tsx and app/global-error.tsx) and a 404 page, so the user sees a way back and not a blank screen.

Stripe's checklist adds the test data: try your integration with incomplete data, invalid data and duplicate data, and pay attention to what you show users, because a declined card is a different message from a failure on your own server. Its best line is that someone else should test the integration, "especially if that other person isn't a developer". Click through these by hand before launch:

• A brand-new account with no data yet
• A slow or dropped connection in the middle of saving
• A form submitted twice in a row
• A session that expired while the tab was open
• A declined card and a cancelled checkout
• A link to a record that was deleted

Data migrations and backups: can you change the schema safely?

In a prototype the AI edits the live database and nobody minds. With real rows in it, every schema change needs to be a file you can read, replay and roll forward. Supabase's migration docs recommend never changing the schema directly on the remote database, because that bypasses the migration history.

If the prototype's schema was built by clicking or prompting, supabase db pull is the starting point: it captures what exists as the first migration. From then on, the rule for your coding agent is one line in its instructions file: schema changes go in a new migration, never in the dashboard.

Backups are the other half. Checked October 2026, Supabase backs up Pro, Team and Enterprise projects daily and keeps 7, 14 and up to 30 days respectively. The backups page lists no automatic backups for the Free plan and recommends exporting with db dump; the production checklist adds that Free projects with low activity over 7 days may be paused. Two details are easy to miss: point-in-time recovery is a paid add-on that needs at least a Small compute add-on, and database backups do not include files stored through the Storage API.

A backup you have never restored is a hope, not a backup. Restore one into a scratch project once. If your backend lives inside an app builder instead, ask the same two questions of it: where is the change history, and how do I get my data out? Our Lovable vs Base44 comparison covers how two builders answer.

Monitoring: how do you find out before your users do?

You need to learn about a failure from a machine, not from a customer email. Vercel's production checklist starts its operations section with an incident response plan that includes rollback strategies, and tells you to get familiar with staging, promoting and rolling back deployments before you need to.

• Persist the logs. The checklist says to enable Log Drains to persist logs from your deployments. Stripe says the same from its side: log important data on your end too.
• Alert on errors. Send them to a channel you read. Vercel lists Observability Plus for investigating errors and traffic on Pro and Enterprise plans.
• Alert on spend. The checklist says to configure Spend Management and its usage alerts. Do the same on the database and on your AI API account.
• Limit abuse. The checklist says to consider rate limiting, and Supabase offers CAPTCHA on its auth endpoints.

Spend alerts matter more for AI products than for most, because one user in a loop can run up a model bill. Our guide to building an AI SaaS has a section on pricing around token costs.

Payments: is the money path live or still in test mode?

Test-mode checkout proves less than it seems to. Stripe's go-live checklist says objects created in a sandbox, such as products and coupons, are not usable in live mode, so they must be recreated with the same IDs. It also says to register live webhook endpoints and confirm they handle delayed notifications, duplicate notifications and events that arrive out of order.

This stretch, from locked data to live billing, is where most prototypes stall. Our AI SaaS Builder program takes it in order: Supabase database design, Row Level Security and authentication, deployment on Vercel, production hardening for the Claude API, then pricing models and Stripe integration.

Vibe coding real projects: a one-week hardening plan

The pass fits in a week if you stop adding features while you do it. That is the hard part. Every new prompt adds surface the checklist has to cover again.

How to make the AI do the hardening work

The tool that wrote the app can check it, as long as it checks with fresh eyes and shows evidence. Asking the same chat "is this secure?" mostly returns reassurance.

• In Claude Code, the built-in /security-review command checks the current diff for security vulnerabilities and /code-review checks it for correctness bugs. A Stop hook can keep a turn from ending while tests fail. Our spec-driven development walkthrough wires those gates together.
• In Lovable, a Quick scan runs automatically every time you publish and flags tables without row-level security and vulnerable dependencies. A Deep scan, run on demand, reviews application code for access control, leaked secrets, unsafe input, payments and authentication.
• In any tool, ask for artefacts you can check: a list of every table with its policies, and a test that signs in as one user and requests another user's rows.

Scans narrow the search; they do not close it. Lovable's own docs say its security tools "do not replace a thorough security review" and that you are responsible for meeting the security requirements of your use case. Treat a clean scan as permission to run the two-account test, not as a substitute for it.

When is a vibe-coded app not ready for production?

Two questions decide it: what the app holds, and whether anyone has reviewed the code that guards it.

The bottom-right cell is where vibe coding earns its bad reputation, and it is avoidable. A few hours of review on authentication, policies and the payment webhook is a small cost next to a week of building.

Mistakes that keep a prototype a prototype

• Adding features during the hardening week. Each one reopens data access and error handling. Freeze first.
• Treating a clean scan as a pass. Scanners find known patterns. The two-account test finds your bug.
• Testing as one user. Almost every data leak needs a second account to see.
• Editing the schema in the dashboard after launch. The next migration will not know about it.
• Leaving payment objects in test mode. Recreate products and webhooks in live mode and run one real payment.
• Having no rollback. Know which button restores the previous deployment before you need it.

Vibe coding production apps: FAQ