v0 app to production

What you already own, and what you should check

v0 builds with Next.js, Tailwind and shadcn/ui, the same stack many production teams use. Vercel states that it does not own the code v0 generates for you, so the codebase is yours to keep.

Connect the project to GitHub from Project settings. v0 creates a private repository and pushes the current code, and from then on that repository is the source of truth. Pick a company GitHub organization as the owner, not a personal account, because deleting the repository can make the code unrecoverable.

Databases are where ownership gets blurry. Adding Neon, Supabase or Upstash from v0 goes through the Vercel Marketplace, which provisions a new account on that service and writes the environment variables into your project. Find out which login owns each of those accounts and who gets the bill before real customer data lands there.

What breaks first in a v0 app

• Publish goes straight to production. With GitHub connected, Publish opens or reuses a pull request, merges it into the base branch and waits for the production deploy. Without branch protection, nothing stops a broken change from merging.
• A demo backend. Data persistence was added to make flows work in a preview. Tables often lack constraints, and server actions trust whatever the client sends.
• Auth added late. Login, roles and session checks get bolted onto pages one prompt at a time, so some routes and server actions stay open.
• One set of environment variables. Production, Preview and Development can each have their own variables on Vercel. Generated projects often point every preview at the production database.
• No tests in CI. v0 can fix a failing CI check, but only if there is a check to fail. Most generated projects ship with none.

Step by step: v0 to production

1. Connect the project to a GitHub repository owned by your company organization.
2. Turn on branch protection for the production branch with required status checks and at least 1 required review. v0 follows these rules and keeps the pull request open until they pass.
3. Move each Marketplace database and service to company billing, and give Production, Preview and Development their own environment variables and their own database.
4. Put every server action and API route behind an auth check and a role check on the server, not only in the UI.
5. Add constraints, foreign keys and Row Level Security or equivalent access rules to the data model, then rotate any key that was ever exposed to the browser.
6. Add tests for the 3 workflows that make you money and run them in CI on every pull request.
7. Add error monitoring, uptime alerts and daily database backups, then point your domain at production.

The 3 ways to production, and what each costs

• Harden in place, from $5,000, 2 to 3 weeks. Lock down the database, fix auth, move secrets to the server, add monitoring. The frontend stays as it is. Right when you have under a few hundred users and the product still changes weekly.
• Rebuild the backend, keep the front, $15,000 to $25,000, 6 to 8 weeks. New API layer, cleaned data model, real permissions, integrations moved server side, tests and CI. Right when users like the product but the plumbing cannot be trusted with money or personal data.
• Full production rebuild, $25,000 to $35,000, 8 to 10 weeks. Same product decisions on a new stack, UX fixes from real usage, AI features designed in. Right when you are charging money, growing, and know exactly what version 2 should be.

When you should not move yet

If nobody pays yet, keep building in v0. Connect GitHub, turn on branch protection and split the production database from previews this week, because those 3 changes are cheap now and painful after launch.