Lovable AI Builder Beperkingen: Wanneer Herschrijven naar Next.js
Vertalen naar Nederlands
Ik heb dit patroon nu een dozijn keer zien gebeuren. Een oprichter zet in een weekend een SaaS-prototype in Lovable op. Het ziet er geweldig uit. Investeerders zijn onder de indruk. Gebruikers melden zich aan. Dan slaat de werkelijkheid toe: Google indexeert je marketingpagina's niet, de auth-flow breekt wanneer je teamwerkruimten toevoegt, je Supabase-queries beginnen met elkaar te botsen in verschillende tenants, en je realiseert je dat je tegen het tool vecht in plaats van je product bouwt.
Lovable is echt indrukwekkend voor wat het doet. Maar er zit een plafond op, en als je een echt SaaS-product bouwt, ga je het raken. Dit artikel legt exact uit waar Lovable tekortschiet, wanneer je een migratie naar custom Next.js moet plannen, en hoe je de herschrijving aanpakt zonder gek te worden.
Inhoudsopgave
- Lovable's architectuur begrijpen
- Het SEO-probleem: CSR is een dood spoor voor openbare pagina's
- Auth-complexiteit verder dan basislogin
- Multi-tenant data: waar Lovable geen antwoord heeft
- Schalen voorbij starter SaaS
- Wanneer migreren: het besluitvormingsraamwerk
- Hoe je de herschrijving aanpakt
- Lovable versus custom Next.js: naast elkaar vergelijking
- Veelgestelde vragen
Lovable's architectuur begrijpen
Voordat we het hebben over beperkingen, laten we duidelijk zijn over wat Lovable eigenlijk produceert. Onder de motorkap genereert Lovable een Vite + React applicatie met client-side rendering (CSR). Dat is het. Geen server-side rendering. Geen static site generation. Geen incremental static regeneration. Puur CSR.
Dit is geen geheim -- Lovable's eigen FAQ over rendering erkent dit. Ze bevelen prerendering aan als een workaround voor SEO, en ze zijn eerlijk dat SSR "moeilijker is met Lovable's huidige setup."
De gegenereerde code gebruikt doorgaans:
- React Router voor client-side navigatie
- Supabase voor auth en database
- Tailwind CSS voor styling
- shadcn/ui componenten
Voor een intern hulpmiddel, een dashboard achter auth, of een snel prototype? Deze stack is volkomen fijn. De problemen beginnen wanneer je productvereisten groeien voorbij wat een single-page application kan afhandelen.
Wat Lovable goed doet
Eerlijk gezegd is Lovable uitzonderlijk in:
- Snelheid naar prototype: Je kunt in enkele uren een werkende UI hebben, niet weken
- Ontwerpkwaliteit: De gegenereerde interfaces zien er netjes uit uit de doos
- Supabase-integratie: Basic auth-flows en CRUD-operaties werken snel
- Componentkwaliteit: De shadcn/ui-componenten die het genereert zijn production-grade
Het probleem is niet kwaliteit -- het is bereik. Lovable optimaliseert voor het zo snel mogelijk bereiken van v0.1. Het optimaliseert niet voor het bereiken van v2.0.
Het SEO-probleem: CSR is een dood spoor voor openbare pagina's
Dit is de meest directe en pijnlijke beperking, en het is degene die oprichters overrompelt. Als je SaaS openbare pagina's heeft -- een marketingsite, een blog, documentatie, prijspagina's, door gebruikers gegenereerde inhoud die indexeerbaar zou moeten zijn -- werkt Lovable's CSR-architectuur actief tegen je.
Dit is wat gebeurt wanneer een crawler een Lovable-gegenereerde pagina raakt:
<!-- Wat Googlebot (soms) ziet -->
<!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>
Die lege <div id="root"> is je volledige pagina-inhoud voor zover de meeste crawlers zich bezorgd maken. Google's Web Rendering Service (WRS) kan JavaScript uitvoeren en CSR-inhoud renderen, maar er zijn echte problemen met dit:
- Het is niet gegarandeerd. Google kan je JavaScript wel of niet renderen. Wanneer het dat doet, kan er een vertraging van uren tot dagen zijn tussen ontdekking en rendering.
- Elke andere crawler faalt. LLM-crawlers (GPTBot, ClaudeBot, PerplexityBot), social media unfurlers (Facebook, LinkedIn, Twitter/X, Slack, Discord), Bing's renderer (minder betrouwbaar dan Google's) -- geen van deze voert JavaScript betrouwbaar uit.
- Delen op sociale media is kapot. Deel een Lovable-pagina op LinkedIn en je krijgt een lege voorbeeldkaart. Dat is een slechte eerste indruk voor een product dat je probeert te laten groeien.
- Zichtbaarheid in AI-zoekopdrachten is nul. Dit wordt in 2026 steeds belangrijker. Als Perplexity, ChatGPT search, of Claude je inhoud niet kunnen zien, besta je niet in AI-gegenereerde antwoorden.
Zoals Nati Elimelech aanwees in een veel gedeelde LinkedIn-post: "Lovable's architectuur (Vite + React CSR) is fundamenteel incompatibel met moderne crawler-vereisten."
Lovable's prerendering workaround
Lovable biedt prerendering als een workaround. Dit converteert je dynamische React-app naar statische HTML bij build-time. Het werkt voor echt statische pagina's -- een eenvoudige landingspagina, een about-pagina. Maar het valt uit elkaar voor:
- Bloginhoud die regelmatig wordt bijgewerkt (je zou op elke publicatie opnieuw moeten bouwen)
- Dynamische productpagina's (bijv. sjabloonengalerieën, marketplace-listings)
- Door gebruikers gegenereerde openbare profielen
- Documentatie met versiebeheer
- Elke pagina waar inhoud meer dan eens per dag verandert
Vergelijk dit met Next.js, waarbij je per-route rendering-controle krijgt:
// Statische generatie bij build-time (zoals een blogpost)
export async function generateStaticParams() {
const posts = await getAllPosts();
return posts.map((post) => ({ slug: post.slug }));
}
// Server-side rendering bij elke aanvraag (zoals een gebruikersprofiel)
export const dynamic = 'force-dynamic';
// Incremental static regeneration (revalideer elke 60 seconden)
export const revalidate = 60;
Deze per-route flexibiliteit kan Lovable eenvoudig niet bieden. Wanneer we Next.js-projecten voor clients bouwen, is deze granulaire rendering-controle vaak de enige grootste reden waarom ze van een CSR-only tool zijn gemigreerd.
Auth-complexiteit verder dan basislogin
Lovable's Supabase-integratie handelt de basis af: email/wachtwoord-aanmelding, magic links, misschien OAuth met Google. Dat is genoeg voor een prototype. Het is niet genoeg voor een productie SaaS.
Hier wordt auth ingewikkeld en kan Lovable niet bijhouden:
Role-Based Access Control (RBAC)
Echte SaaS-apps hebben rollen nodig. Een eigenaar, admin, lid, viewer-hiërarchie op zijn minst. Wanneer je in Lovable bent, betekent het implementeren van RBAC:
- Het schrijven van aangepaste Supabase RLS (Row Level Security) policies met de hand
- Het beheren van rolstatus aan de clientzijde (wat inherent onveilig is voor autorisatiebeslissingen)
- Het bouwen van je eigen middleware-achtige logica in React-componenten
In Next.js handelt je autorisatie op het serverniveau af voordat inhoud wordt verzonden:
// middleware.ts -- loopt voordat de pagina wordt weergegeven
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();
}
Dit loopt op de server. De onbevoegde gebruiker ziet de instellingenpagina nooit, ontvangt nooit de HTML, krijgt nooit de JavaScript-bundel. In een CSR-app stuur je de code en verberg je deze met client-side checks -- wat elke gemotiveerde gebruiker kan omzeilen.
Sessiebeheer over subdomeinen
Als je SaaS subdomains gebruikt (zoals acme.yourapp.com), heb je cookies nodig die over subdomains werken, token-vernieuingslogica die randgevallen afhandelt, en sessievalidatie die niet tussen tenants lekt. Lovable geeft je niet de server-side infrastructuur om dit af te handelen. Je eindigt met het samenstellen van workarounds die in productie breken.
Enterprise SSO (SAML/OIDC)
Zodra je aan bedrijven met meer dan 50 werknemers verkoopt, vraagt iemand naar SAML- of OIDC-integratie. Dit vereist server-side callback-handling, token-uitwisseling, en veilige sessieoprichting. Het is fundamenteel een server-side flow. Het proberen in een CSR-only app te implementeren is tegen de zwaartekracht strijden.
Multi-tenant data: waar Lovable geen antwoord heeft
Multi-tenancy is de definiërende architectuuruitdaging van SaaS. Elke aanvraag moet aan de juiste organisatie worden gekoppeld. Elke query moet filteren op tenant. Elke gegevenseenheid heeft isolatiegaranties nodig.
Lovable geeft je Supabase, die kan multi-tenancy afhandelen via RLS-policies. Maar de patronen op toepassingsniveau -- routing, context, data fetching -- liggen volledig bij jou, en Lovable's AI genereert geen multi-tenant-bewuste code.
De twee patronen
| Patroon | Voorbeeld | Voordelen | Nadelen |
|---|---|---|---|
| Op basis van pad | app.com/[team]/dashboard |
Eenvoudig hosten, geen DNS-config | Minder merkbaar voor klanten |
| Op basis van subdomain | team.app.com |
Betere white-labeling, schonere URL's | Vereist wildcard SSL, DNS-config, middleware-routing |
Next.js ondersteunt beide natively. De App Router's dynamische segmenten hanteren pad-gebaseerde routing elegant:
app/
[teamSlug]/
dashboard/
page.tsx
settings/
page.tsx
billing/
page.tsx
Voor subdomain-gebaseerde routing kan Next.js middleware het subdomain extraheren en de tenant omzetten voordat pagina-code loopt:
// middleware.ts
export function middleware(request) {
const hostname = request.headers.get('host');
const subdomain = hostname?.split('.')[0];
// Herschrijf de URL om tenant-context op te nemen
if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
return NextResponse.rewrite(
new URL(`/${subdomain}${request.nextUrl.pathname}`, request.url)
);
}
}
In Lovable zou je dit bedraad hebben met React Router en aangepaste hooks, client-side fetch-oproepen doen om de tenant op te lossen, en omgaan met flitsen van foute-tenant-inhoud tijdens laadtoestanden. Ik heb gezien dat dit misgaat. Het is niet prettig.
Gegevensisolatiezorgen
De enge multi-tenancy-bug is een gegevenslekking -- Tenant A's gegevens tonen aan Tenant B. In een server-rendered architectuur kun je tenant-scoping afdwingen op de datalaag voordat het antwoord wordt verzonden. In CSR vertrouw je op client-side code om de juiste tenant-ID aan je API door te geven, en hoop je dat je RLS-policies al het overige opvangen.
RLS is je vangnet, niet je primaire verdediging. Je primaire verdediging moet server-side middleware zijn die tenant-context bij elke aanvraag valideert. Lovable geeft je die laag niet.
Schalen voorbij starter SaaS
Er is een set problemen die niet opdoken totdat je echte gebruikers, echte gegevens, en echte bedrijfsvereisten hebt. Lovable's gegenereerde code is niet ontworpen voor deze scenario's.
Prestatie schaal
Een Lovable-app stuurt je volledige applicatie als een JavaScript-bundel. Naarmate je app groeit, groeit ook die bundel. React Router laadt alles in het geheugen op de client. Gebruikers met tragere verbindingen of oudere apparaten voelen dit.
Next.js geeft je automatische code-splitsing op routeniveau. Navigeer naar /dashboard en je laadt alleen dashboard-code. Navigeer naar /settings en alleen settings-code laadt. Dit is automatisch -- je configureert het niet.
Achtergrondtaken en server-logica
Echte SaaS-apps hebben behoefte aan:
- Webhook-handlers (Stripe, SendGrid, third-party integraties)
- Geplande taken (factureringscycli, rapportgeneratie, gegevensopschoning)
- E-mailverzending met server-side sjablonen
- PDF-generatie
- Bestandsverwerking
Niets hiervan is mogelijk in een CSR-only applicatie. Je zou een aparte backend nodig hebben. Met Next.js kun je webhooks en server-logica direct afhandelen:
// 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 });
}
Dit is een echt API-eindpunt met server-side code, in dezelfde codebase als je frontend. Geen aparte Express-server. Geen aparte deployment.
Testen en CI/CD
Lovable-gegenereerde projecten komen niet met test-infrastructuur. Geen unit-tests, geen integratietests, geen E2E-tests. Voor een prototype is dat prima. Voor productie SaaS die klantbetalingen en gevoelige gegevens afhandelt, is het een aansprakelijkheid.
Next.js-projecten integreren natuurlijk met Jest, Vitest, Playwright, en Cypress. Je kunt server-componenten, API-routes, en middleware in isolatie testen.
Wanneer migreren: het besluitvormingsraamwerk
Niet elk Lovable-project heeft een herschrijving nodig. Hier is een praktisch raamwerk:
Blijf op Lovable als:
- Je pre-product-market fit bent en nog aan het valideren
- Je app volledig achter authenticatie staat (geen openbare pagina's nodig voor SEO)
- Je een single-tenant model hebt (één gebruiker, één account)
- Het een intern hulpmiddel of admin panel is
- Je team geen ontwikkelaarbronnen heeft
Plan een migratie als:
- Je organisch zoekverkeer naar openbare pagina's nodig hebt
- Je team/organisatie-werkruimten toevoegt
- Enterprise-klanten vragen naar SSO
- Je Supabase RLS-policies worden een spaghettiwarboel
- Je server-side integraties nodig hebt (webhooks, betalingsverwerking)
- Paginalaadtijden nemen toe naarmate je app groeit
- Je meer tijd besteedt aan het bestrijden van Lovable dan aan het bouwen van functies
Migreer onmiddellijk als:
- Je een (of bijna een) multi-tenant gegevenslekking hebt gehad
- Google Search Console toont indexeeringsfouten op belangrijke pagina's
- Je deals verliest vanwege SSO/veiligheidsvereisten
- Je client-bundel overschrijdt 500KB gzipped
Hoe je de herschrijving aanpakt
Het ergste wat je kunt doen is een big-bang herschrijving proberen waarbij je alles opnieuw opbouwt en een knop omzet. Zo gaan herschrijvingen dood.
Het Strangler Fig-patroon
De slimste aanpak is incrementeel. Implementeer je Next.js-app naast je Lovable-app en migreer routes een voor een.
- Begin met openbare pagina's. Verplaats je marketingsite, blog, en docs naar Next.js met proper SSR/SSG. Dit geeft je directe SEO-winsten.
- Verplaats de auth-laag. Implementeer je auth-flow in Next.js middleware. Dit is het moeilijkste onderdeel -- doe het vroeg.
- Migreer functies per functies. Begin met de eenvoudigste pagina's en werk naar de meest complexe toe.
- Hergebruik je componenten. Lovable genereert React-componenten. De meeste zullen met minimale wijzigingen in Next.js werken -- vooral het verwijderen van React Router-afhankelijkheden en het converteren naar bestand-gebaseerde routing.
Er is zelfs een CLI-tool (NextLovable) die een deel van de structurele conversie automatiseert:
npx @nextlovable/cli convert ./src/components/ -f app-router
Het handelt de bestandsstructuurconversie van Lovable's vlakke componentdirectory naar Next.js App Router's geneste layout-patroon af. Het handelt je bedrijfslogica niet af, maar het bespaart uren tedieuse bestandsverplaatsing.
Wat te begroten
Een realistische migratietijdlijn voor een SaaS van middelmatige complexiteit (10-20 pagina's, auth, basis multi-tenancy):
| Fase | Tijdlijn | Inspanning |
|---|---|---|
| Openbare pagina's + SEO | 1-2 weken | Laag |
| Auth + middleware | 2-3 weken | Hoog |
| Dashboard-migratie | 3-4 weken | Gemiddeld |
| API-routes + webhooks | 1-2 weken | Gemiddeld |
| Testen + QA | 1-2 weken | Gemiddeld |
| Totaal | 8-13 weken | -- |
Als je niet drie maanden aan migratie wilt besteden, is dat precies het soort project dat we aanpakken. We hebben er genoeg van gedaan om te weten waar de landmijnen zijn.
Lovable versus custom Next.js: naast elkaar vergelijking
| Mogelijkheid | Lovable (Vite + React CSR) | Custom Next.js |
|---|---|---|
| Tijd naar prototype | Uren | Dagen tot weken |
| SSR / SSG / ISR | ❌ Geen (alleen prerendering) | ✅ Volledige ondersteuning, per-route |
| SEO voor openbare pagina's | ⚠️ Slecht (afhankelijk van Google's JS-rendering) | ✅ Uitstekend |
| AI-zoekvisiebiliteit | ❌ Onzichtbaar voor LLM-crawlers | ✅ Volledig zichtbaar |
| Voorbeeld-kaarten delen op sociale media | ❌ Kapot | ✅ Dynamische OG-afbeeldingen |
| Multi-tenancy | ⚠️ Handmatig, alleen client-side | ✅ Middleware + server-side |
| Auth (basis) | ✅ Supabase-integratie | ✅ Meerdere providers |
| Auth (enterprise SSO) | ❌ Geen server-side ondersteuning | ✅ SAML/OIDC-ondersteuning |
| API-routes | ❌ Aparte backend nodig | ✅ Built-in |
| Code-splitsing | ⚠️ Handmatig | ✅ Automatisch per-route |
| Test-infrastructuur | ❌ Geen gegenereerd | ✅ Volledig ecosysteem |
| Deploymentflexibiliteit | Lovable hosting of Netlify/Vercel (statisch) | Vercel, AWS, Docker, self-hosted |
| Kosten schaal | $20-50/ma (Lovable) + Supabase | Hosting varieert ($0-200+/ma) |
Veelgestelde vragen
Kan ik Lovable gebruiken voor mijn SaaS marketingsite en Next.js voor de app? Dat kan, maar het creëert onderhoudslast. Je hebt twee codebases, twee deployment pipelines, en mogelijk inconsistent ontwerp. Een beter uitgangspunt is alles in Next.js bouwen -- gebruik statische generatie voor marketingpagina's en server-componenten voor de app. Als je al op Lovable bent, begin met het migreren van alleen de openbare pagina's naar Next.js en houdt de app op Lovable totdat je gereed bent voor een volledige migratie.
Lost Lovable's prerendering het SEO-probleem op? Deels. Prerendering genereert statische HTML bij build-time, die crawlers kunnen lezen. Het werkt voor pagina's die zelden veranderen -- een about-pagina, een prijspagina. Maar het werkt niet voor dynamische inhoud zoals blogposts die regelmatig worden bijgewerkt, door gebruikers gegenereerde inhoud, of marketplace-listings. Je zou bij elke inhoudswijziging een rebuild moeten triggeren, wat snel onpraktisch wordt. Next.js's ISR (Incremental Static Regeneration) handelt dit elegant af door pagina's op een schema of on-demand opnieuw te valideren.
Hoeveel kost een Lovable-naar-Next.js migratie doorgaans? Voor een eenvoudig prototype (5-10 pagina's, basis auth), verwacht 2-4 weken ontwikkelaarstijd. Voor een SaaS van middelmatige complexiteit met multi-tenancy, aangepaste auth-flows, en API-integraties, budget 8-13 weken. Bij agencyuurtarieven is dat ongeveer $15.000-$50.000 afhankelijk van complexiteit. Je kunt onze prijzen controleren of contact opnemen voor een scoped schatting op basis van je werkelijke codebase.
Is het mogelijk om geleidelijk van Lovable naar Next.js te migreren? Absoluut, en het is de aanbevolen aanpak. Gebruik het strangler fig-patroon: implementeer Next.js naast je Lovable-app, migreer routes een voor een beginnend met openbare pagina's, en gebruik een reverse proxy of DNS-routing om beide apps van hetzelfde domein te serveren. Tools zoals NextLovable's CLI kunnen delen van de structurele conversie automatiseren.
Wat dacht je van Astro in plaats van Next.js voor de openbare pagina's? Astro is uitstekend voor inhoudszware sites met minimale interactiviteit. Als je openbare pagina's vooral statische marketinginhoud zijn en je app een aparte SPA is, is Astro een geweldige keuze. Maar als je één uniforme codebase voor zowel marketingpagina's als je dynamische app wilt, is Next.js de praktischer optie. We bouwen met beide afhankelijk van de client's behoeften -- het komt neer op hoeveel interactiviteit je openbare pagina's nodig hebben.
Zullen mijn Lovable React-componenten in Next.js werken?
De meeste met kleine wijzigingen. De belangrijkste wijzigingen zijn: React Router-imports verwijderen en in plaats daarvan Next.js Link en useRouter gebruiken, 'use client' directives toevoegen aan componenten die hooks gebruiken zoals useState of useEffect, en Lovable-specifieke utilities vervangen. De componentlogica en styling (Tailwind-klassen, shadcn/ui-componenten) dragen direct over.
Wat als ik geen ontwikkelaar ben -- kan ik toch weg van Lovable? Ja, maar je hebt helpende ontwikkelaars nodig. De migratie is een technisch project. Je kunt een freelance Next.js-ontwikkelaar inhuren, een headless development agency zoals wij gebruiken, of de NextLovable CLI gebruiken om een voorzet te krijgen en daarna hulp binnenhalen voor de complexe onderdelen. Het goede nieuws is dat Lovable's gegenereerde code schoon en goed gestructureerd is, wat het makkelijker maakt voor een ontwikkelaar om mee te werken dan met de meeste AI-gegenereerde codebases.
Wanneer is Lovable in 2026 nog steeds de juiste keuze? Lovable is ideaal voor interne tools, admin panels, dashboards die achter auth leven, MVP's die je aan investeerders toont, en snelle prototypes voor gebruikerstests. Als niemand buiten je team je app door zoekopdracht hoeft te vinden, en je hebt geen complexe auth of multi-tenancy nodig, kan Lovable je verrassend ver brengen. De sleutel is eerlijk tegen jezelf zijn over wanneer je erbuiten bent gegroeid -- en niet wachten totdat de technische schuld je verplettert om de migratie te plannen.