When to migrate a Lovable app to Next.js (and when to leave it alone)

Most Lovable founders export their MVP and immediately ask the same question: should we rewrite this in Next.js? The honest answer is usually no, until three specific pressures show up.

We talk to founders every week who shipped a working product on Lovable in a weekend, picked up early users, and now wonder if the stack underneath them will hold. Lovable did exactly what it promised: it got them from idea to running app faster than a hired team could have written a kickoff doc. The question isn't whether Lovable was the right choice to start. It's whether it's still the right choice now, and what the alternative actually costs.

This is the useful stack decision: what Lovable ships out of the box, which three pressures justify a Next.js migration, when a monorepo earns its keep, and which questions to answer before spending a week on a rewrite.

What Lovable ships, and why it's tuned for speed

Lovable's default generated frontend is React + Vite + TypeScript, with Tailwind, shadcn/ui, and Radix UI. Routing is client-side via react-router. The build output is a single-page app bundle that drops onto static hosting. When you add persistence, auth, storage, or Edge Functions, the backend is usually Lovable Cloud or a Supabase project you control.

That stack is optimized for one thing: how quickly the AI can generate something that runs in a browser. It does that job well. It is also a common, reasonable product stack, widely supported, easy to extend, and familiar to most React engineers. There's nothing wrong with a Vite SPA. There's something wrong with a Vite SPA when you start asking it to do things SPAs are bad at.

A note on timing: a third-party migration shop reported in April 2026 that some new Lovable projects were shipping on TanStack Start with SSR. Lovable's public FAQ still lists React + Vite + TypeScript as the default, so check the exported repo and page source before assuming which stack you are on.

Pressure one: SEO exposes the app-shell problem

This is the blunt forcing function. The initial HTML response of a Vite SPA is often just an app shell. Google can render JavaScript, but rendering is queued and limited; other crawlers and social scrapers may not run it at all. Routes like /pricing, /about, and /product/123 can therefore index late, index incompletely, or fail link previews unless the meaningful content exists in server-rendered or statically generated HTML.

If your business depends on organic search, content, comparison pages, or programmatic SEO, this is not a meta-tag tuning problem. It's a rendering strategy problem. Server-side rendering, static generation, or a serious prerendering layer gives crawlers content in the first response, and Next.js is the well-paved path. Performance still matters: older Google/SOASTA mobile page-speed research found bounce probability rose roughly 32% when load time moved from one second to three.

Run a simple test: view source on /pricing, /about, and one public product page. If the text a buyer or crawler needs is missing from the initial HTML, your public surface needs SSR or SSG. Behind-auth dashboards usually don't. Be honest about which one you're running.

Pressure two: scale starts flattening the bundle

The second forcing function is bundle size and waterfalls. SPAs ship the entire bundle, then start fetching data. Next.js's App Router does code-splitting automatically, moves data fetching to the server, and uses Suspense to stream pages in the order you actually want them.

Early reports of React Server Component adoption show 18-29% client bundle reductions versus equivalent SPA implementations. For a Lovable app where the AI generated everything as a client component, that isn't a free lunch, it's a meaningful refactor, but the ceiling is real. You also pick up the Metadata API, image optimization, font optimization, and per-page choice between build-time, request-time, and client fetching.

The architectural difference is simple. Vite is a build tool. Next.js is a framework. If your product has grown past one screen and one fetch, the framework starts paying for itself.

Pressure three: you have more than one app

The monorepo question is independent of the Vite-vs-Next.js question. You can run a single Next.js app in a single repo and be perfectly happy for years.

The monorepo question is: do you have multiple apps that share code? Web plus admin. Web plus mobile. Web plus a partner-facing portal. Once you have two consumers of the same component library, the same Supabase types, or the same API contract, "copy and paste between two repos" stops working around the third week.

Mintlify's team-size framing matches what we see in practice: 1-5 developers usually do better with separate repos, while 6-20 developers can justify a monorepo when projects are highly interdependent. Our additional rule of thumb is shared code: if at least 30% of components, types, or API contracts are genuinely reused across apps, Turborepo plus pnpm workspaces starts paying back. Below that, you're paying the monorepo tax for minimal benefit.

What the migration actually costs

Public migration writeups give useful edges, not a universal estimate. Inngest moved its Dev Server app from Vite to Next.js in less than a day. NextLovable, a migration vendor, advertises a one-to-two-week Lovable-to-Next.js path at $2,500+. Full productionization roadmaps with proper testing, CI/CD, and a real design system commonly sit in the six-to-twelve-week range.

Here's our estimate after an audit for a typical Lovable SaaS, say 10-30 routes, Supabase Auth, a few integrations, no React Native client yet:

• Phase 1 (Next.js shell, still SPA underneath): 1-2 days. Drop Next.js into the existing repo, keep react-router, keep client-side fetching. Nothing about user behavior or SEO has improved yet. This is the foundation, not the win.
• Phase 1 + 2 (App Router migration): 1-2 weeks. Each route becomes a folder under app/. Marketing routes first, they benefit most from SSG and have the fewest data dependencies. Auth pages next. Authenticated routes last.
• Phase 1 + 2 + 3 (server components + proper data layer): 2-4 weeks. Decide per route whether it's 'use client' or server. Decide per mutation whether it's a Server Action, an API route, or a tRPC procedure.
• Phase 1 + 2 + 3 + 4 (lift into a monorepo): 3-5 weeks. Only worth it if you have at least two apps and at least three packages worth extracting.

The hosting math also moves. A Vite SPA on Cloudflare Pages is effectively free for most pre-launch SaaS. Next.js on Vercel Pro starts at $20/month with one deploying seat included; additional deploying seats are $20/month each, with compute and bandwidth overages after included allocations. A five-engineer team starts around $100/month before meaningful usage, but viewer seats are free. None of that is a reason not to migrate. It is a reason to plan where you'll host before you start.

Imagine you're 14 months into a Lovable build

Imagine you're a non-technical founder running a B2B SaaS you started on Lovable. You have 400 paying users, $18K in MRR, an in-house engineer you hired three months ago, and a content marketing plan that's about to ship 40 SEO landing pages. Your engineer can keep extending the Lovable codebase, but every change they make to a generated component takes longer than it should, and Search Console shows that Google is discovering your homepage while pricing and comparison pages have weak or missing indexed content.

This is the canonical migration moment. You have the user count, the revenue, the engineer, and a concrete reason that SEO matters this quarter. Phase 1 plus Phase 2 is a two-week job for many teams at this size. The public pages can ship with meaningful HTML instead of waiting on client-side rendering. You haven't bet the company on a rewrite, you've graduated the front end to a stack that can carry your distribution plan.

Now imagine the same founder with 40 users, no engineer, and no content plan. The right answer is to keep shipping features on Lovable, hire the engineer first, and revisit this conversation when organic traffic, ownership, or scale becomes a current-quarter constraint.

When not to migrate

The honest counter-list. Pushing back on a migration is often the right call.

• You have under 100 paying users and no organic traffic plan this quarter. SEO doesn't matter yet. Stay on Lovable, ship features, and revisit when distribution depends on public pages.
• Your app is a behind-auth dashboard. SEO is irrelevant. Vite has documented HMR around 150ms versus a few seconds for Next.js, simpler mental model, and cheaper hosting. The "Next.js for marketing, Vite for the app" hybrid is becoming a defensible default.
• You're a solo founder with one app. A monorepo adds friction with no organizational benefit. Stay single-repo.
• You don't have anyone who can own the codebase post-migration. Migrating to Next.js and then handing it back to a non-engineer is worse than staying on Lovable. The whole point of leaving is moving from "AI-managed, you can't touch it" to "engineer-owned, you can extend it."
• You're still iterating on product-market fit weekly. A migration is one to four weeks of frozen feature dev. If you don't yet know what the product is, don't pay that cost.

A decision matrix you can run in five minutes

Here's the framework we use when a founder asks us to audit their Lovable export.

Run it as a flow. Does your business depend on organic search? If no, stay on Lovable for the app and maybe add a separate Next.js marketing site later. If yes, do you have an engineer who will own the codebase after the migration? If no, hire first. If yes, is it one app or multiple? One app means a single Next.js repo. Multiple apps with at least 30% shared code means Turborepo plus pnpm workspaces. And if you have at least two clients or three or more developers touching the API, tRPC's typesafety dividend pays back fast. Below that, Server Actions for mutations plus the Supabase client for queries is enough.

One more question worth asking: are you on Lovable Cloud rather than a Supabase project in your own account? If you cannot see the project, service role, or database URL in your own Supabase dashboard, plan a database custody step before, or alongside, the framework migration. Don't ship to production on infrastructure you don't own.

Ship fast on Lovable, migrate deliberately

Lovable is a great way to get from zero to "users are touching this." Our view is narrower: once organic search, infrastructure custody, compliance, or multi-app code sharing becomes business-critical, the codebase needs an engineer-owned plan. The natural arc is: build the MVP on Lovable, validate that users want it, then migrate only the parts that need to carry the next two years.

Migrate when SEO becomes a forcing function, when bundle and waterfall pain shows up in Core Web Vitals, or when you have a second app sharing real code with the first. Don't migrate because Twitter said you should, because your investor mentioned Next.js, or because you read a blog post that called Vite SPAs obsolete. They aren't.

If you're trying to figure out where you sit on this matrix, book a call and we'll audit your Lovable export, map which routes need SSR or SSG, check Supabase custody, and give you a realistic phase plan for your team. Our engineering and AI teams have done this migration enough times that we usually know the answer in a 30-minute conversation, including, often, "don't migrate yet."

Source note: stack, pricing, and crawler behavior were checked in May 2026 against public docs and posts from Lovable, Supabase, Next.js, Google Search Central, Vercel, Mintlify, Inngest, NextLovable, and Ministry of Programming.

Ship fast on Lovable. Migrate deliberately. Stay small. Build big.