Vibe-Coded Prototype to Production: The Lovable to Claude Code Handoff (2026)

What you get

• Convert a Lovable prototype into a version-controlled repo with CI in under 3 hours
• Get to test coverage on the paths that matter (auth, payments, data writes) before launch
• Cut the rewrite that kills most vibe-coded projects down to a targeted 3-5 day hardening pass
• Ship to production behind a real CI pipeline for $90/mo in tools

Step-by-Step Workflow

7 steps · 3 hours to set up · 3-5 focused days ongoing

1. 1

   Freeze the prototype and get it into Git

   Stop prompting in Lovable and export the current state to a GitHub repo. Clone it locally. This freezes a known-good version you can always return to. From here, every change is a commit you can review, revert, and deploy, which is the entire point of the handoff.

   

   20 minOutput: A GitHub repo with the prototype as commit oneTools: Lovable

   Tip: Tag this commit 'prototype-baseline'. When the hardening pass breaks something, you can diff against the version you know worked.

2. 2

   Have Claude Code audit the codebase

   Run Claude Code in the repo and ask for a production-readiness audit against a specific list: exposed secrets, missing input validation, absent auth checks on server routes, missing row-level security, and lack of tests. Ask for findings as a prioritized list, not fixes yet. You want the map before you start driving.

   

   30 minOutput: A ranked list of production gaps with file referencesTools: Claude Code

   Tip: Ask it to rank by blast radius: anything touching payments, auth, or cross-user data reads is P0. Cosmetic issues are P3 and can wait.

3. 3

   Move secrets and lock down the backend

   Fix the P0 security findings first. Move any keys out of client code into server-side env vars, enable Supabase row-level security with per-user policies, and add auth checks to every server route that writes or reads user data. Have Claude Code implement each fix as a separate commit so you can review them in isolation.

   3-4 hrsOutput: No exposed secrets, RLS on, auth enforced on every protected routeTools: Claude Code, Supabase

   Tip: Write one RLS policy by hand and have Claude Code follow the pattern for the rest. Blindly generated policies are the easiest way to lock yourself out or leave a table open.

4. 4

   Add tests where risk lives

   You do not need full coverage. You need tests on the paths where a bug costs you money or trust: authentication, the paid action, and any write that touches another user's data. Have Claude Code write these tests, run them, and fix what fails. This is the safety net that lets you keep shipping fast after the handoff.

   3-4 hrsOutput: A test suite covering auth, payments, and cross-user writesTools: Claude Code

   Tip: Test the failure cases, not just the happy path. 'Unpaid user cannot access the paid action' catches more real bugs than 'paid user can'.

5. 5

   Set up CI and preview deploys

   Connect the repo to Vercel so every branch gets a preview URL and every merge to main deploys. Have Claude Code write a GitHub Actions workflow that runs the tests and a type check on every PR, blocking merge on failure. Now a broken commit cannot reach production, which is the line between a prototype and a product.

   1-2 hrsOutput: CI that runs tests on every PR and blocks merge on red; preview deploy per branchTools: Vercel, Claude Code

   Tip: Require the CI check to pass before merge in GitHub branch protection. A pipeline that does not block is theater.

6. 6

   Route AI changes through PRs with review

   From now on, Claude Code opens a branch and a PR for every change rather than committing to main. Turn on CodeRabbit (or Graphite Agent) so each PR gets an automated review pass. This gives the fast AI-driven work a checkpoint, which matters most precisely when you are moving quickly and skipping your own review.

   

   30 min setup, then ongoingOutput: Every AI change lands via a reviewed PR, not a direct pushTools: CodeRabbit, Claude Code

   Tip: Read the AI review, but do not accept it blindly either. Treat CodeRabbit as a second opinion, not an approver.

7. 7

   Cut over to production and verify

   Point your custom domain at the Vercel production deploy, swap in production Supabase and any live third-party keys, and run a full end-to-end pass as a brand-new user in an incognito window. Sign up, use the paid action, and confirm data lands correctly with RLS enforced. Only then announce it is live.

   1-2 hrsOutput: A verified production deployment on your domainTools: Vercel, Supabase

   Tip: Do the incognito run before you tell anyone. Finding the broken signup yourself is free; finding it via a churned first user is not.

What a prototype is missing, specifically

A Lovable or Bolt prototype almost always ships with the same five gaps: no automated tests, secrets or API keys committed or exposed client-side, missing input validation on writes, no row-level security so any user can read any row, and no CI so a broken commit reaches production. None of these are visible when you click through the demo. All of them surface the day a real user hits an edge you did not click. The handoff is a checklist against exactly these gaps, not a vague 'make it production-grade'.