I've seen this pattern play out a dozen times now. A founder spins up a SaaS prototype in Lovable over a weekend. It looks great. Investors are impressed. Users sign up. Then reality hits: Google isn't indexing the marketing pages, the auth flow breaks when you add team workspaces, your Supabase queries start colliding across tenants, and you realize you're fighting the tool instead of building your product.

Lovable is genuinely impressive for what it does. But there's a ceiling, and if you're building a real SaaS product, you're going to hit it. This article breaks down exactly where Lovable falls short, when you should plan a migration to custom Next.js, and how to approach the rewrite without losing your mind.

Table of Contents

Lovable AI Builder Limitations: When to Rewrite in Next.js

Understanding Lovable's Architecture

Before we talk about limitations, let's be clear about what Lovable actually produces. Under the hood, Lovable generates a Vite + React application with client-side rendering (CSR). That's it. No server-side rendering. No static site generation. No incremental static regeneration. Pure CSR.

This isn't a secret -- Lovable's own FAQ on rendering acknowledges it. They recommend prerendering as a workaround for SEO, and they're honest that SSR is "harder with Lovable's current setup."

The generated code typically uses:

  • React Router for client-side navigation
  • Supabase for auth and database
  • Tailwind CSS for styling
  • shadcn/ui components

For an internal tool, a dashboard behind auth, or a rapid prototype? This stack is perfectly fine. The problems start when your product requirements grow beyond what a single-page application can handle.

What Lovable Gets Right

Credit where it's due. Lovable is exceptional at:

  • Speed to prototype: You can have a working UI in hours, not weeks
  • Design quality: The generated interfaces look polished out of the box
  • Supabase integration: Basic auth flows and CRUD operations work quickly
  • Component quality: The shadcn/ui components it generates are production-grade

The issue isn't quality -- it's scope. Lovable optimizes for getting to v0.1 as fast as possible. It doesn't optimize for getting to v2.0.

The SEO Problem: CSR Is a Dead End for Public Pages

This is the most immediate and painful limitation, and it's the one that catches founders off guard. If your SaaS has any public-facing pages -- a marketing site, a blog, documentation, pricing pages, user-generated content that should be indexable -- Lovable's CSR architecture is actively working against you.

Here's what happens when a crawler hits a Lovable-generated page:

<!-- What Googlebot (sometimes) sees -->
<!DOCTYPE html>
<html>
  <head>
    <title>My SaaS App</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index-abc123.js"></script>
  </body>
</html>

That empty <div id="root"> is your entire page content as far as most crawlers are concerned. Google's Web Rendering Service (WRS) can execute JavaScript and render CSR content, but there are real problems with this:

  1. It's not guaranteed. Google may or may not render your JavaScript. When it does, there can be a delay of hours to days between discovery and rendering.
  2. Every other crawler fails. LLM crawlers (GPTBot, ClaudeBot, PerplexityBot), social media unfurlers (Facebook, LinkedIn, Twitter/X, Slack, Discord), Bing's renderer (less reliable than Google's) -- none of these reliably execute JavaScript.
  3. Social sharing is broken. Share a Lovable page on LinkedIn and you get a blank preview card. That's a terrible first impression for a product you're trying to grow.
  4. AI search visibility is zero. This is increasingly important in 2026. If Perplexity, ChatGPT search, or Claude can't see your content, you don't exist in AI-generated answers.

As Nati Elimelech pointed out in a widely-shared LinkedIn post: "Lovable's architecture (Vite + React CSR) is fundamentally incompatible with modern crawler requirements."

Lovable's Prerendering Workaround

Lovable does offer prerendering as a workaround. This converts your dynamic React app into static HTML at build time. It works for truly static pages -- a simple landing page, an about page. But it falls apart for:

  • Blog content that updates frequently (you'd need to rebuild on every publish)
  • Dynamic product pages (e.g., template galleries, marketplace listings)
  • User-generated public profiles
  • Documentation with versioning
  • Any page where content changes more than once a day

Compare this to Next.js, where you get per-route rendering control:

// Static generation at build time (like a blog post)
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// Server-side rendering on every request (like a user profile)
export const dynamic = 'force-dynamic';

// Incremental static regeneration (revalidate every 60 seconds)
export const revalidate = 60;

This per-route flexibility is something Lovable simply can't offer. When we build Next.js projects for clients, this granular rendering control is often the single biggest reason they migrated from a CSR-only tool.

Auth Complexity Beyond Basic Login

Lovable's Supabase integration handles the basics: email/password sign-up, magic links, maybe OAuth with Google. That's enough for a prototype. It's not enough for a production SaaS.

Here's where auth gets complicated and Lovable can't keep up:

Role-Based Access Control (RBAC)

Real SaaS apps need roles. An owner, admin, member, viewer hierarchy at minimum. When you're in Lovable, implementing RBAC means:

  • Writing custom Supabase RLS (Row Level Security) policies by hand
  • Managing role state on the client side (which is inherently insecure for authorization decisions)
  • Building your own middleware-like logic in React components

In Next.js, you handle authorization at the server level before any content is sent:

// middleware.ts -- runs before the page renders
import { NextResponse } from 'next/server';
import { createServerClient } from '@supabase/ssr';

export async function middleware(request) {
  const supabase = createServerClient(/* config */);
  const { data: { user } } = await supabase.auth.getUser();
  
  if (!user) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  const { data: membership } = await supabase
    .from('team_members')
    .select('role')
    .eq('user_id', user.id)
    .eq('team_id', extractTeamId(request.url))
    .single();

  if (membership?.role !== 'admin' && request.nextUrl.pathname.includes('/settings')) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.next();
}

This runs on the server. The unauthorized user never sees the settings page, never receives the HTML, never gets the JavaScript bundle. In a CSR app, you're shipping the code and hiding it with client-side checks -- which any motivated user can bypass.

Session Management Across Subdomains

If your SaaS uses subdomains (like acme.yourapp.com), you need cookies that work across subdomains, token refresh logic that handles edge cases, and session validation that doesn't leak between tenants. Lovable doesn't give you the server-side infrastructure to handle this. You end up hacking together workarounds that break in production.

Enterprise SSO (SAML/OIDC)

Once you're selling to companies with more than 50 employees, someone will ask for SAML or OIDC integration. This requires server-side callback handling, token exchange, and secure session creation. It's fundamentally a server-side flow. Trying to implement it in a CSR-only app is fighting gravity.

Lovable AI Builder Limitations: When to Rewrite in Next.js - architecture

Multi-Tenant Data: Where Lovable Has No Answer

Multi-tenancy is the defining architectural challenge of SaaS. Every request needs to be scoped to the right organization. Every query needs to filter by tenant. Every piece of data needs isolation guarantees.

Lovable gives you Supabase, which can handle multi-tenancy through RLS policies. But the application-level patterns -- routing, context, data fetching -- are entirely on you, and Lovable's AI doesn't generate multi-tenant-aware code.

The Two Patterns

Pattern Example Pros Cons
Path-based app.com/[team]/dashboard Simple hosting, no DNS config Less brand-able for customers
Subdomain-based team.app.com Better white-labeling, cleaner URLs Requires wildcard SSL, DNS config, middleware routing

Next.js supports both natively. The App Router's dynamic segments handle path-based routing elegantly:

app/
  [teamSlug]/
    dashboard/
      page.tsx
    settings/
      page.tsx
    billing/
      page.tsx

For subdomain-based routing, Next.js middleware can extract the subdomain and resolve the tenant before any page code runs:

// middleware.ts
export function middleware(request) {
  const hostname = request.headers.get('host');
  const subdomain = hostname?.split('.')[0];
  
  // Rewrite the URL to include tenant context
  if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
    return NextResponse.rewrite(
      new URL(`/${subdomain}${request.nextUrl.pathname}`, request.url)
    );
  }
}

In Lovable, you'd be wiring this up with React Router and custom hooks, making client-side fetch calls to resolve the tenant, and dealing with flashes of wrong-tenant content during loading states. I've seen this go wrong. It's not pretty.

Data Isolation Concerns

The scariest multi-tenancy bug is a data leak -- showing Tenant A's data to Tenant B. In a server-rendered architecture, you can enforce tenant scoping at the data layer before the response is sent. In CSR, you're trusting client-side code to pass the right tenant ID to your API, and hoping your RLS policies catch everything else.

RLS is your safety net, not your primary defense. Your primary defense should be server-side middleware that validates tenant context on every request. Lovable doesn't give you that layer.

Scaling Beyond Starter SaaS

There's a set of problems that don't show up until you have real users, real data, and real business requirements. Lovable's generated code isn't designed for these scenarios.

Performance at Scale

A Lovable app ships your entire application as a JavaScript bundle. As your app grows, so does that bundle. React Router loads everything into memory on the client. Users on slower connections or older devices feel this.

Next.js gives you automatic code splitting at the route level. Navigate to /dashboard and you only load dashboard code. Navigate to /settings and only settings code loads. This is automatic -- you don't configure it.

Background Jobs and Server Logic

Real SaaS apps need:

  • Webhook handlers (Stripe, SendGrid, third-party integrations)
  • Scheduled jobs (billing cycles, report generation, data cleanup)
  • Email sending with server-side templates
  • PDF generation
  • File processing

None of this is possible in a CSR-only application. You'd need a separate backend. With Next.js, you can handle webhooks and server logic directly:

// app/api/webhooks/stripe/route.ts
export async function POST(request: Request) {
  const body = await request.text();
  const sig = request.headers.get('stripe-signature');
  
  const event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
  
  switch (event.type) {
    case 'customer.subscription.updated':
      await updateSubscription(event.data.object);
      break;
    case 'invoice.payment_failed':
      await handleFailedPayment(event.data.object);
      break;
  }
  
  return Response.json({ received: true });
}

This is a real API endpoint running server-side code, in the same codebase as your frontend. No separate Express server. No separate deployment.

Testing and CI/CD

Lovable-generated projects don't come with test infrastructure. No unit tests, no integration tests, no E2E tests. For a prototype, that's fine. For production SaaS handling customer payments and sensitive data, it's a liability.

Next.js projects integrate naturally with Jest, Vitest, Playwright, and Cypress. You can test server components, API routes, and middleware in isolation.

When to Migrate: The Decision Framework

Not every Lovable project needs a rewrite. Here's a practical framework:

Stay on Lovable if:

  • You're pre-product-market fit and still validating
  • Your app is entirely behind authentication (no public pages needed for SEO)
  • You have a single-tenant model (one user, one account)
  • You're an internal tool or admin panel
  • Your team has no developer resources

Plan a migration if:

  • You need organic search traffic to public pages
  • You're adding team/organization workspaces
  • Enterprise customers are asking for SSO
  • Your Supabase RLS policies are becoming a spaghetti mess
  • You need server-side integrations (webhooks, payment processing)
  • Page load times are creeping up as your app grows
  • You're spending more time fighting Lovable than building features

Migrate immediately if:

  • You've had (or nearly had) a multi-tenant data leak
  • Google Search Console shows indexing failures on important pages
  • You're losing deals because of SSO/security requirements
  • Your client bundle exceeds 500KB gzipped

How to Approach the Rewrite

The worst thing you can do is attempt a big-bang rewrite where you rebuild everything from scratch and flip a switch. That's how rewrites die.

The Strangler Fig Pattern

The smartest approach is incremental. Deploy your Next.js app alongside your Lovable app and migrate routes one at a time.

  1. Start with public pages. Move your marketing site, blog, and docs to Next.js with proper SSR/SSG. This gives you immediate SEO wins.
  2. Move the auth layer. Implement your auth flow in Next.js middleware. This is the hardest part -- do it early.
  3. Migrate feature by feature. Start with the simplest pages and work toward the most complex.
  4. Reuse your components. Lovable generates React components. Most of them will work in Next.js with minimal changes -- mainly removing React Router dependencies and converting to file-based routing.

There's even a CLI tool (NextLovable) that automates some of the structural conversion:

npx @nextlovable/cli convert ./src/components/ -f app-router

It handles the file structure conversion from Lovable's flat component directory to Next.js App Router's nested layout pattern. It won't handle your business logic, but it saves hours of tedious file moving.

What to Budget

A realistic migration timeline for a mid-complexity SaaS (10-20 pages, auth, basic multi-tenancy):

Phase Timeline Effort
Public pages + SEO 1-2 weeks Low
Auth + middleware 2-3 weeks High
Dashboard migration 3-4 weeks Medium
API routes + webhooks 1-2 weeks Medium
Testing + QA 1-2 weeks Medium
Total 8-13 weeks --

If you'd rather not spend three months on migration, that's exactly the kind of project we handle. We've done enough of these to know where the landmines are.

Lovable vs Custom Next.js: Side-by-Side Comparison

Capability Lovable (Vite + React CSR) Custom Next.js
Time to prototype Hours Days to weeks
SSR / SSG / ISR ❌ None (prerendering only) ✅ Full support, per-route
SEO for public pages ⚠️ Poor (depends on Google's JS rendering) ✅ Excellent
AI search visibility ❌ Invisible to LLM crawlers ✅ Fully visible
Social preview cards ❌ Broken ✅ Dynamic OG images
Multi-tenancy ⚠️ Manual, client-side only ✅ Middleware + server-side
Auth (basic) ✅ Supabase integration ✅ Multiple providers
Auth (enterprise SSO) ❌ No server-side support ✅ SAML/OIDC support
API routes ❌ Need separate backend ✅ Built-in
Code splitting ⚠️ Manual ✅ Automatic per-route
Testing infrastructure ❌ None generated ✅ Full ecosystem
Deployment flexibility Lovable hosting or Netlify/Vercel (static) Vercel, AWS, Docker, self-hosted
Cost at scale $20-50/mo (Lovable) + Supabase Hosting varies ($0-200+/mo)

FAQ

Can I use Lovable for my SaaS marketing site and Next.js for the app?

You can, but it creates maintenance overhead. You'll have two codebases, two deployment pipelines, and potentially inconsistent design. A better approach is building everything in Next.js -- use static generation for marketing pages and server components for the app. If you're already on Lovable, start by migrating just the public-facing pages to Next.js and keep the app on Lovable until you're ready for a full migration.

Does Lovable's prerendering solve the SEO problem?

Partially. Prerendering generates static HTML at build time, which crawlers can read. It works for pages that rarely change -- an about page, a pricing page. But it doesn't work for dynamic content like blog posts that update frequently, user-generated content, or marketplace listings. You'd need to trigger a rebuild every time content changes, which gets impractical fast. Next.js's ISR (Incremental Static Regeneration) handles this elegantly by revalidating pages on a schedule or on-demand.

How much does a Lovable-to-Next.js migration typically cost?

For a simple prototype (5-10 pages, basic auth), expect 2-4 weeks of developer time. For a mid-complexity SaaS with multi-tenancy, custom auth flows, and API integrations, budget 8-13 weeks. At agency rates, that's roughly $15,000-$50,000 depending on complexity. You can check our pricing for specifics, or get in touch for a scoped estimate based on your actual codebase.

Is it possible to gradually migrate from Lovable to Next.js?

Absolutely, and it's the recommended approach. Use the strangler fig pattern: deploy Next.js alongside your Lovable app, migrate routes one at a time starting with public-facing pages, and use a reverse proxy or DNS routing to serve both apps from the same domain. Tools like NextLovable's CLI can automate parts of the structural conversion.

What about Astro instead of Next.js for the public pages?

Astro is excellent for content-heavy sites with minimal interactivity. If your public pages are mostly static marketing content and your app is a separate SPA, Astro is a great choice. But if you want one unified codebase for both marketing pages and your dynamic app, Next.js is the more practical option. We build with both depending on the client's needs -- it comes down to how much interactivity your public pages require.

Will my Lovable React components work in Next.js?

Most of them will with minor modifications. The main changes are: removing React Router imports and using Next.js Link and useRouter instead, adding 'use client' directives to components that use hooks like useState or useEffect, and replacing any Lovable-specific utilities. The component logic and styling (Tailwind classes, shadcn/ui components) transfer directly.

What if I'm not a developer -- can I still move away from Lovable?

Yes, but you'll need developer help. The migration is a technical project. You can hire a freelance Next.js developer, use a headless development agency like us, or use the NextLovable CLI to get a head start and then bring in help for the complex parts. The good news is that Lovable's generated code is clean and well-structured, which makes it easier for a developer to work with than most AI-generated codebases.

When is Lovable still the right choice in 2026?

Lovable is ideal for internal tools, admin panels, dashboards that live behind auth, MVPs you're showing to investors, and rapid prototypes for user testing. If nobody outside your team needs to find your app through search, and you don't need complex auth or multi-tenancy, Lovable can take you surprisingly far. The key is being honest with yourself about when you've outgrown it -- and not waiting until the technical debt is crushing you to start planning the migration.