v0 app to production: what a developer fixes

Taking a v0 app to production rarely needs a rewrite, because v0 generates standard Next.js, React and Tailwind code. What a developer fixes is everything v0 skips to make the preview look finished: keeping secrets and auth checks on the server, adding real metadata and a sitemap so Google can index the site, setting security headers, passing Core Web Vitals, and picking hosting that still makes sense once real traffic shows up. Published cleanup packages for AI-built apps mostly cost $1,500 to $8,000.

My Bolt.new post covered the general production checklist for AI-built apps, and my Lovable post explained why a client-rendered app can be invisible to Google. v0 is a different case. It outputs Next.js, React and Tailwind, which is the same stack I build marketing sites and web apps on. So the foundation is fine. What's missing is the work around it.

Why isn't a v0 app production-ready out of the box?

A v0 app isn't production-ready because v0 is built to get a working UI preview in front of you fast. Checking security, SEO and hosting isn't its job, so that's left to a developer.

v0 runs on credits, with a free tier and paid plans (v0 pricing). It's genuinely good at UI. What it won't do is stop and ask whether your API key just ended up in the browser, or whether Google is reading a generic title tag on every page.

This isn't only a v0 problem. In Veracode's 2025 GenAI Code Security Report, AI-generated code introduced security flaws in 45% of the tasks tested.

Here are the usual gaps in a v0 app, in the order I'd fix them:

What breaks with auth and secrets in a v0 app?

The biggest risks in a v0 app are API keys exposed to the browser and auth that's only checked in Next.js middleware. Either one can cost you money or data, so I always start here.

Exposed keys. In Next.js, any environment variable prefixed NEXT_PUBLIC_ is inlined into the JavaScript sent to the browser. If a v0 prototype calls OpenAI, Stripe or a database straight from a client component, that key is public. Anyone can open dev tools, copy it and run up your bill. The fix: move those calls into Server Components, Route Handlers or Server Actions, rotate every key that was ever exposed, and keep separate keys for preview and production.

The chat on my own AI portfolio runs on the Claude API, and I follow the same rule there. The browser talks to my server. Only the server talks to the model.

Auth that only lives in middleware. AI tools like to protect a dashboard with one middleware check. I don't trust that on its own. In March 2025, CVE-2025-29927 let attackers skip Next.js middleware entirely by sending a single crafted header. It was patched in Next.js 15.2.3 and 14.2.25, but the lesson still applies. The Next.js data security guide recommends checking authorisation close to the data and treating every Server Action like a public API endpoint. That's exactly what a Server Action is.

Database rules. If your v0 app uses Supabase, check that Row Level Security is switched on and every table has policies. A Supabase service-role key in client code bypasses all of them.

Will Google index a v0 app?

Yes, Google can index a v0 app, because Next.js renders HTML on the server. That puts v0 well ahead of a client-rendered Lovable or Bolt.new app. Four common gaps still hold indexing back, though.

1. Placeholder metadata. The generated root layout often ships with a generic title and description, and every page inherits it. Each route needs its own title, description, canonical URL and Open Graph image, set through the Next.js Metadata API. One catch: metadata and generateMetadata only work in Server Components. If v0 put "use client" at the top of a whole page, you'll have to split that page before you can add metadata at all.
2. Content fetched in the browser. Client components still pre-render, but data loaded in useEffect doesn't. Product lists, blog posts and pricing tables loaded that way reach crawlers as empty skeletons. Moving the fetch to the server fixes it.
3. No sitemap or robots file. Next.js generates both from a sitemap.ts and a robots.ts file. v0 prototypes rarely include either. Once they're live, submit the sitemap in Google Search Console.
4. No structured data. Organisation, product, article and FAQ schema help Google and AI answer engines understand what a page is about.

My free tools handle the tedious parts. The Meta Tag Generator writes titles and descriptions, the Schema Markup Generator produces JSON-LD, and the AI Crawler Checker tells you if your robots.txt is blocking GPTBot, ClaudeBot or PerplexityBot by accident. If you'd rather hand the whole thing over, that's my technical SEO and Core Web Vitals service.

Which security headers does a v0 app need?

A v0 app needs Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, because Next.js doesn't set a CSP or HSTS for you. You add them in the headers() function in next.config, or with a nonce-based policy in middleware if you need inline scripts (Next.js CSP guide). My baseline:

• Content-Security-Policy: limits where scripts, styles and frames can load from, and sets frame-ancestors to stop clickjacking.
• Strict-Transport-Security: forces HTTPS.
• X-Content-Type-Options: nosniff, Referrer-Policy and Permissions-Policy.
• poweredByHeader: false, so you stop advertising the framework.

CSP is where it gets fiddly. Analytics, Stripe, HubSpot and chat widgets all need their domains allowed, and a policy that's too strict can quietly break checkout without any obvious error. I've spent a lot of time on exactly this: my HTTP Security Header plugin sets these same headers on WordPress and has 1,000+ active installs. Run your live URL through the Security Headers Checker before launch, then again after.

Why does a v0 app fail Core Web Vitals?

v0 apps usually fail Core Web Vitals because of unoptimised images, too much client-side JavaScript, unmanaged fonts and scripts, and layout shift. Google's thresholds for a good experience are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

• Images served unoptimised. It's common to find images: { unoptimized: true } in a v0-generated next.config. That switches off resizing and modern formats. Turn it back on and use next/image with explicit sizes.
• Too much client JavaScript. When big sections are client components, the browser has to download and hydrate code that could have stayed on the server. On a mid-range phone, that shows up in INP.
• Fonts and third-party scripts. Use next/font, and load analytics and widgets with next/script at the right strategy.
• Layout shift from skeleton loaders and images without dimensions.

While you're in next.config, look for typescript.ignoreBuildErrors. The Next.js docs call it dangerous, and I agree: it lets broken code ship to production. For a ranked list of fixes, paste your PageSpeed report into my free Page Speed Fix Planner.

Should you deploy a v0 app on Vercel or Cloudflare?

For most founders, Vercel is the right first home for a v0 app, because v0 deploys there in one click. Cloudflare Workers is worth the extra setup once traffic or hosting cost makes it worth it.

My advice: launch on Vercel and only revisit it when the bill or a specific need pushes you. I go through the trade-offs in more detail in Vercel vs Cloudflare for Next.js.

How much does it cost to take a v0 app to production?

Published cleanup packages for AI-built apps mostly cost $1,500 to $8,000, with a full published range of $299 to $40,000. Nobody has a settled market rate for v0 specifically yet, but these figures give you a working range:

The price moves with a few things: whether there's auth and user data, whether there are payments, how many pages fetch data in the browser, whether content has to move into a CMS, and how much of the code needs tests. A brochure site with a form sits near the bottom of these ranges. A SaaS app with logins and Stripe sits near the top.

Timelines work the same way. A small v0 marketing site can be hardened in days. A v0 app with accounts, a database and billing usually takes a few weeks, and most of that goes on auth and testing.

1. 1

   Audit

   Read the repo, list exposed secrets, unprotected actions, client-side data fetching and build warnings.

2. 2

   Lock down secrets and auth

   Move keys to the server, rotate them, add authorisation checks to every action and route, and check database rules.

3. 3

   Fix SEO foundations

   Per-page metadata, sitemap.ts, robots.ts, canonicals, structured data and server-rendered content.

4. 4

   Headers and performance

   Set CSP and HSTS, re-enable image optimisation and cut client JavaScript until Core Web Vitals pass.

5. 5

   Deploy and monitor

   Production hosting, environment variables per stage, error tracking, Search Console and analytics.

What should you ask a developer before hiring?

Before you hire anyone, ask whether they'll keep or rewrite your v0 code, how they'll deal with exposed secrets and auth, and who owns the repo, hosting and domain afterwards. The questions I'd want a client to ask me:

• Will you keep the v0 code or rewrite it, and why?
• How will you find and rotate secrets that were exposed while prototyping?
• Where will auth be checked: middleware only, or in every action and route?
• Which security headers will you set, and how will you test CSP against Stripe and analytics?
• What Core Web Vitals scores will you target on mobile, and how will you measure them?
• Vercel or Cloudflare for my traffic, and what will hosting cost each month?
• Will I own the GitHub repo, hosting account and domain?

A good answer to the first question is usually "keep most of it". v0's UI code is often perfectly usable. The plumbing underneath is what needs a senior developer looking at it.

If you've got a v0 prototype you want to launch, send me the repo link or a preview URL through contact and I'll tell you what needs fixing before it goes live. You can book a 20-minute discovery call on the same page, or read about my Next.js and React websites service first.