I vibe coded an app. Now what?

Congratulations: the part that felt hard is done, and what is left is a known list. Before real users arrive, keep secrets out of the repo and the browser, turn on row level security, check sign-up and payments on the production URL, set your env vars on the host, and add error monitoring and backups. Then put the app on your own domain with working email, publish a privacy policy and terms, and plan launch day so you can watch it and roll back.

Why this matters

On your machine, everything runs as you: your keys, your test account, your data, one database. Real users change three things. Strangers can call your database and API directly, not only through the screens you built. Money and email start moving through providers that keep test and live setups apart. And when something breaks, you are not watching the terminal. The steps below handle those changes in order of risk.

The steps, in order

Repo hygiene and secrets: real keys out of git and out of the browser.
Database access: row level security on every table.
Auth: every sign-in flow works on the production URL.
Payments and webhooks: verified events, and live mode set up.
Env vars on the host, per environment.
Error monitoring that alerts you.
Backups you know how to restore.
A custom domain and working email.
Legal basics: a privacy policy and terms.
A launch day plan.

Each step, and the guide that goes deeper

Steps 1 and 2 close holes that expose data to anyone, so do them first even if launch is tomorrow.

1. Repo hygiene and secrets

Check that .env, .env.local and any other file with a real key is listed in .gitignore and is not already tracked. If a real key was ever committed, rotate it before anything else. GitHub's guide puts rotating the secret first: a rotated key no longer works, and someone may already have a clone.

Then sort your keys into two piles. The browser may hold the Supabase publishable or anon key and the Stripe publishable key. Only the server may hold the Supabase secret or service role key, the Stripe secret or restricted key, and every other provider key. Next.js inlines any variable prefixed NEXT_PUBLIC_ into the browser bundle at build time, so a secret behind that prefix is public.

# env files git already tracks
git ls-files -- '.env*' '*/.env*'

# commits that ever touched them
git log --all --oneline -- .env .env.local

Go deeper: Supabase service role key leaked or exposed: how do I rotate it?

2. Database access: row level security

With Supabase, the frontend talks to the database directly through the Data API, using a key anyone can read in your page source. What keeps a stranger from reading every row is row level security (RLS). Supabase's docs: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." RLS is a table setting you turn on with alter table ... enable row level security, so a table your agent created in SQL or a migration needs it turned on explicitly.

Run this in the SQL editor. Every row it returns is a public table with RLS off. Turn it on, add a policy for each action the app needs that compares the row's owner with auth.uid(), and read the condition of every existing policy: using (true) lets everyone through.

select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Go deeper: How do I find Supabase tables missing RLS in my migrations?

3. Auth

Walk through sign-up, email confirmation, sign-in, password reset and sign-out on the production URL, not localhost. In Supabase, the Site URL starts as http://localhost:3000 and is the default redirect for confirmation and reset emails, so Supabase says to change it to your production URL. Add your Vercel preview URLs to the redirect allow list with a wildcard, and keep the production entry exact.

Then check authorization: every API route and server action that reads or changes data should check on the server who the user is. Hiding a button does not stop anyone from calling the route.

Go deeper: AI App Auth Production Checklist

4. Payments and webhooks

If you take money with Stripe, the webhook is usually where a payment turns into access. Verify every event with the Stripe-Signature header and constructEvent over the raw request body; Stripe's docs warn that a framework that parses or changes the body breaks verification. Without that check, anyone who finds the URL can post a fake "checkout completed" event.

Going live is its own setup. Stripe says objects created in a sandbox, such as products and prices, are not usable in live mode, live webhook endpoints are registered separately from test ones, and each endpoint gets its own signing secret. Stripe also asks that your handler copes with delayed, duplicate and out-of-order events.

Go deeper: Stripe Webhook Checklist for AI-Built Apps

5. Env vars on the host

Your .env.local does not deploy. Every variable the code reads has to be set in the Vercel project, under the right environment: Production, Preview or Development. Vercel applies a change only to new deployments, so redeploy after you add or edit one. Keep live Stripe keys in Production and test keys in Preview, so a preview build does not charge real cards.

# what Vercel has, per environment
vercel env ls production
vercel env ls preview

Go deeper: Vercel Environment Variables Checklist for AI Apps

6. Error monitoring

Without monitoring you hear about errors from users, if at all. Vercel keeps runtime logs from your functions, for an hour on the Hobby plan and a day on Pro, and those logs do not include errors that happen in your visitors' browsers. Add an error tracker such as Sentry to the frontend and the server, throw a test error from the production deployment to see it arrive, and turn on an alert for new issues.

Go deeper: Error Monitoring Launch Checklist for AI-Built Apps

7. Backups

Find out what you could restore before you need to. Supabase's backups guide says it backs up Pro, Team and Enterprise projects daily, with the last 7 days available on Pro, and recommends that Free Plan projects export their data regularly with supabase db dump and keep off-site copies. Database backups do not include the files in Storage, only their metadata.

With the project linked (supabase link), these three commands save roles, schema and data. They run pg_dump in a container, so Docker has to be running. Keep production credentials away from your coding agent too: two incidents in the guide below began with an agent that could reach a live database.

supabase db dump -f roles.sql --role-only
supabase db dump -f schema.sql
supabase db dump -f data.sql --use-copy --data-only

Go deeper: What went wrong in the real vibe coding horror stories?

8. A custom domain and email

Add your domain in the Vercel project under Settings, then Domains. An apex domain such as example.com is configured with an A record and a subdomain with a CNAME, and Vercel suggests adding www as well. If you move your nameservers to Vercel instead, Vercel says to copy your existing DNS records first, including the MX records your email depends on.

Then fix auth email. Supabase's built-in SMTP server is for trying things out: without a custom SMTP server it only sends to members of your Supabase team, and it is limited to 2 messages per hour. Set up a custom SMTP provider before launch, sending from your own domain, or new users will not get their confirmation emails. Change the Supabase Site URL to the new domain too.

Go deeper: Vercel Preview to Production Checklist

9. Legal basics

This is a pointer, not legal advice. Before you collect personal data such as email addresses, or take payments, look up what the law requires where you and your users are; that commonly includes a privacy policy and terms of service. Start from a reputable template or a lawyer, and list the services that handle user data, such as your host, database, payments, email and monitoring.

10. A launch day plan

Launch when you can watch for a few hours, not on your way out the door. Before you post, sign up, pay and do the core action as a new user on the production URL in a private window. Keep the error tracker and the Vercel and Supabase logs open.

Know your way back. Vercel's Instant Rollback puts a previous production deployment back in place, though on the Hobby plan only the one immediately before; a database migration needs its own way back, so keep migrations small on launch week. If you expect a spike, check the auth email limit: with a custom SMTP provider Supabase starts you at 30 new users per hour, and says a major public announcement will likely need more.

Go deeper: How to Launch an AI-Built App Safely

Optional repo check

For AI-built Vercel + Supabase apps, there is one optional check before you deploy: npx -y viberaven@1.6.3 check, a pre-deploy review for vibe-coded Vercel + Supabase apps that reads the repo for parts of steps 1, 2, 4, 5 and 6. In a run on a fixture repo on 2026-10-05 it reported a .env file not covered by .gitignore, a public table without RLS, using (true) policies, NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in .env.example, a security definer function the anon key could call, a Stripe webhook handler with no signature check, env vars the code reads that .env.example does not list, and no Sentry or PostHog in the code. It did not flag a Stripe secret key hardcoded in a client file, and it cannot see your Vercel or Supabase settings, backups, domain, email setup or git history. It is advice, not a gate, and a repository check, not a live database or security test. A clean result does not prove the app is secure. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore.

Related guides

Sources

Do I need to do all ten steps before launch?

Do steps 1 and 2 first: they close holes that let anyone read or change your users' data. Auth, payments and env vars matter as soon as real users sign up or pay. Monitoring, backups, domain, legal and the launch plan can be lighter for a small private beta, but not skipped once strangers use the app.

Can my coding agent do these steps for me?

It can write most of the code and SQL: RLS policies, webhook verification, a .gitignore entry, the error tracker setup. Dashboard settings, rotating keys and deciding what each user may see stay with you, and the agent should not hold your production credentials.