Lovable.dev lets you ship a working app in a weekend. That superpower is real, and it's why we recommend Lovable for prototypes. Once the app starts taking real money from real users, the same template that got you to launch becomes the thing holding you back.
This playbook walks through the seven steps of migrating a Lovable prototype to a production-grade Nuxt 3 or Next.js app. It's the same process we run on client engagements, written up so you can follow it yourself or use it to brief a development team.
Why migrate at all?
Three reasons. Security first: Lovable's default Supabase RLS is permissive in ways that won't survive a real security audit. Performance next: the generated code talks to Supabase from the client in ways that fall over past a few hundred concurrent users. And extensibility last: the moment you need a custom integration, a non-template payment flow, or a feature Lovable's UI can't express, you hit a wall.
If you don't have these problems, you don't need to migrate. Lovable is fine for what it is. The trigger is usually a specific event: a security review, a scaling incident, an enterprise customer asking for SOC 2, or a feature request that the AI can't reliably generate.
Step 1: Audit the Lovable project
Before you write any new code, understand what you have. Export the Lovable codebase. Map every Supabase table, every Row Level Security rule, every env variable, and every external integration. List the user flows that absolutely must keep working through cutover, typically signup, login, payment, and the core value-delivery flow.
This is usually a 2-3 day exercise. Skip it and you'll find missing data or broken flows during cutover.
Step 2: Choose the target stack
Nuxt 3 on Cloudflare Pages or Next.js on Vercel are the common choices for SaaS migrations. Both work well, both have excellent Stripe and Supabase ecosystems, both deploy fast. The choice usually comes down to which framework your team is more comfortable with.
Keep Supabase as your database unless you have a specific reason to switch. Supabase's Postgres is the same Postgres you'd use anywhere else; the problems with Lovable apps are in the RLS configuration and how the application code talks to Supabase, not Supabase itself.
Step 3: Recreate the schema and tighten RLS
Create a new Supabase project (or a new schema in the existing one). Replay all the table definitions from the source project. Then rewrite every RLS policy.
The principle: the anon role should never have insert, update, or delete on tables holding user data. Authenticated users should only be able to access their own rows. Anything that needs to cross row boundaries, admin actions, cron jobs, customer support tooling, should run via service-role from the backend, never from the client.
This single change typically resolves 70-80% of the security findings in a Lovable audit.
Step 4: Re-implement the UI
Most Lovable apps use Tailwind and shadcn/ui, both of which are portable to Nuxt and Next. The migration is page-by-page: re-implement the highest-traffic routes first, then less-trafficked ones, then admin tools. Keep the visual design identical, your users shouldn't notice the cutover.
Time per page varies a lot. A simple list-detail view might take 2 hours. A complex dashboard with charts and filters might take a day. Plan accordingly.
Step 5: Replace template payments with real Stripe
Lovable's payment integration is a demo. It works for showing investors that money moves, but it lacks the production-grade essentials: webhook signature verification, idempotency keys on every payment intent, robust subscription state machines, customer portal access, automatic refund handling, dunning email logic for failed payments.
Implement Stripe properly. Use Stripe's webhook CLI to test locally. Have a checklist of failure modes (network drop during checkout, double-submit, expired card, disputed charge) and verify each one. This is the single most expensive step to get wrong later.
Step 6: Add observability and CI/CD
Sentry catches errors in production. Axiom or Logflare aggregates logs in a queryable way. An uptime monitor (Better Stack, Pingdom) tells you when the app goes down. These three things together give you the visibility Lovable doesn't.
CI/CD on GitHub Actions: every PR runs lint, typecheck, and tests. Every PR gets a preview deploy. A staging environment mirrors production for QA. Deploying to production becomes boring, which is what you want.
Step 7: Cutover
The DNS cutover is the visible event but the smallest step. Choose a low-traffic window. Keep the Lovable version live and DNS-switchable for 48 hours as a rollback option. Have a monitoring dashboard open with error rates, payment success, and your core user flow metrics.
Communicate to users that maintenance is happening. Make the actual change invisible, same URLs, same UI, same data, same login. Done well, a cutover takes under 30 minutes and your users don't notice.
What this typically costs
A typical Lovable-to-production migration for a SaaS with 1-3 core user flows runs €9,000-€18,000 over 4-8 weeks. Larger apps go higher. The audit and planning phase is a fixed-price entry point (€600-€1,500) and tells you the actual scope before you commit to a budget.
See our Lovable to Production service for engagement details, or read the related guide What Is Vibe Coding and When Does Your AI-Generated App Need Rescue? for context on when this migration is actually worth doing.