Je site exporteren uit Lovable of Bolt: wat krijg je écht mee?

In het eerste deel van deze serie schreven we dat Lovable, Bolt en v0 echte code leveren die je kunt exporteren, in tegenstelling tot Framer of Wix. Dat klopt. Maar "je kunt exporteren" en "je hebt een werkende, onafhankelijke site" zijn niet hetzelfde ding.

Tussen die twee zit een rij technische stappen die de demo's nooit laten zien. In dit artikel lopen we ze door: wat zit er echt in zo'n export, wat ontbreekt, en wat moet je nog regelen voor je site los van het platform draait. Handig als je overweegt te migreren, of als je het verhaal van je ontwikkelaar wilt kunnen controleren.

Korte versie: Lovable en Bolt exporteren je broncode netjes naar GitHub, inclusief het database-schema. Maar je database-inhoud, je gebruikers, je authenticatie-instellingen en je hosting moet je handmatig overzetten. Voor een ervaren developer is een eenvoudige site een dag werk; een productie-site met echte gebruikers en data al snel meerdere dagen. Voor een niet-techneut die juist een AI-builder koos om geen developer nodig te hebben, is het sowieso een muur.

Wat een export wél bevat

Laten we eerlijk zijn over wat goed geregeld is, want Lovable en Bolt doen op dit punt meer dan de gemiddelde no-code tool.

Lovable synct je volledige codebase naar een eigen GitHub-repository. Volgens hun eigen documentatie behoud je 100% eigendom van de code, en het project is gebouwd op open source technologie: React, Vite, Tailwind en Supabase. Bij de export komt niet alleen je frontend mee, maar ook het database-schema en de Row Level Security-policies (de regels die bepalen wie welke data mag zien). Lovable documenteert zelfs actief hoe je je project naar je eigen Supabase verhuist. Dat is een stuk transparanter dan platforms die je opsluiten.

Bolt laat je het project downloaden als ZIP, of synct naar GitHub. Je krijgt de complete projectstructuur in een framework naar keuze (vaak Next.js of een Vite-opzet), die je daarna lokaal kunt draaien met npm install en op Netlify, Vercel of je eigen server kunt deployen. De Bolt-database kopieert de structuur (tabellen en kolommen) mee, en als je een eigen Supabase gebruikt kun je die koppeling behouden.

Tot zover het goede nieuws. De code is van jou, en hij draait op standaard technologie. Het probleem zit in alles eromheen.

Wat een export níet vanzelf meeneemt

Een moderne webapplicatie is meer dan code. Het is code plus data plus configuratie plus hosting. Die laatste drie komen niet mee in je GitHub-repo.

1. De data zelf

Het database-schema (de structuur) komt mee, maar de inhoud niet. Je gebruikers, je bestellingen, je content: die staan in de database van het platform en moet je apart exporteren. Bij Lovable doe je dat per tabel via een CSV-export, of via pg_dump als je dieper wilt. Bij Bolt geldt hetzelfde: een gedupliceerd of geëxporteerd project kopieert de tabelstructuur, maar niet de rijen.

Voor een site met tien pagina's tekst is dat te overzien. Voor een applicatie met duizenden gebruikersrecords is het een migratie-project met alle bijbehorende risico's: kolommen die niet matchen, datatypes die niet kloppen, relaties tussen tabellen die je in de juiste volgorde moet herstellen.

2. Authenticatie en gebruikers

Als je site een inlog heeft, draait die op de auth-laag van het platform (bij Lovable: Supabase Auth). Bij een verhuizing moet je elke login-provider handmatig opnieuw instellen in je nieuwe omgeving. Gebruik je Google- of GitHub-login, dan moet je in de OAuth-instellingen van die diensten de redirect-URL's bijwerken naar je nieuwe adres. Wachtwoorden van bestaande gebruikers migreren is een apart en gevoelig traject.

3. Opslag en bestanden

Geüploade bestanden (afbeeldingen, documenten) staan in de storage-buckets van het platform. Die moet je bucket voor bucket overzetten. De toegangsregels op bucketniveau die je in de UI hebt ingesteld, komen niet automatisch mee, die stel je opnieuw in.

4. Omgevingsvariabelen en secrets

API-sleutels, database-wachtwoorden, koppelingen met betaalproviders of mailservers: die staan als environment variables in het platform en moet je in je nieuwe omgeving opnieuw aanmaken. Ze staan, terecht, niet in je GitHub-repo. Dat betekent ook dat je ze moet weten of opnieuw moet genereren.

5. Hosting en domein

De export geeft je code, geen draaiende site. Je moet zelf hosting regelen, een build-pipeline opzetten, je domein-DNS aanpassen en het geheel testen. Bij v0 is dit extra merkbaar: de deploy-features zijn geoptimaliseerd voor Vercel, dus wil je naar AWS of een andere provider, dan vervallen de voordelen en houd je enkel de code-export over.

In één oogopslag: wat komt mee en wat niet

Onderdeel	Komt mee met de export?	Wat je zelf regelt
Broncode (frontend + backend)	Ja	Niets, staat in je GitHub-repo
Database-schema (structuur)	Ja	Pushen naar je eigen database
Database-inhoud (je data)	Nee	Per tabel exporteren via CSV of `pg_dump`
Gebruikers en authenticatie	Nee	Login-providers en OAuth opnieuw instellen
Geüploade bestanden	Nee	Storage-buckets en policies overzetten
Omgevingsvariabelen en secrets	Nee	Opnieuw aanmaken in je nieuwe omgeving
Hosting en domein	Nee	Zelf hosting, build-pipeline en DNS regelen

Een concreet beeld: van Lovable naar je eigen Supabase

Om het tastbaar te maken, zo ziet een typische Lovable-migratie eruit volgens publieke handleidingen van Supabase-specialisten:

Code synchroniseren naar GitHub en lokaal clonen
Een nieuw Supabase-project aanmaken (managed of self-hosted via Docker)
Het schema en de RLS-policies pushen (die zaten al in je repo)
Per tabel de data exporteren naar CSV en importeren in het nieuwe project
De omgevingsvariabelen (.env) bijwerken naar je nieuwe Supabase-URL en sleutels
Auth-providers opnieuw configureren en OAuth redirect-URL's bijwerken
Storage-buckets kopiëren en bucket-policies opnieuw instellen
Hosting opzetten, deployen, testen, DNS omzetten

Er bestaan gratis open-source tools (zoals de Lovable-to-Supabase exporter onder MIT-licentie) die stap 4 tot en met 7 deels automatiseren. Dat helpt. Maar elk van deze stappen vraagt technische kennis, en bij een productie-site met echte gebruikers wil je dit in een staging-omgeving testen voor je live gaat. Gespecialiseerde bureaus rekenen voor zo'n migratie vanaf zo'n 300 dollar en plannen er drie tot zeven dagen voor in. Dat zegt genoeg over de complexiteit: het is geen exportknop, het is een project.

Waarom dit ertoe doet

Het punt is niet dat Lovable of Bolt je opsluiten. Dat doen ze grotendeels niet, en ze verdienen krediet voor hun openheid. Het punt is dat "exporteerbaar" iets anders is dan "verhuisbaar zonder developer."

Wie een AI-builder kiest, doet dat vaak juist om geen technische partij nodig te hebben. Het ongemakkelijke is dat je op het moment dat je weg wilt, precies die technische partij wél nodig hebt. Je zit dan niet vast door een gesloten formaat, maar door de kloof tussen "ik heb een ZIP met code" en "ik heb een draaiende, onderhouden site."

Vergelijk het met een bouwpakket voor een meubel waar alle onderdelen in zitten, maar zonder schroeven, zonder gereedschap en zonder handleiding. Technisch heb je alles. Praktisch kom je er niet zonder hulp.

Hoe wij hiermee omgaan

Bij GraphicGenie bouwen we op Next.js, met de code in een GitHub-repository en de site op gangbare infrastructuur. Het verschil zit niet in "wij hebben wel code en zij niet", want die hebben Lovable en Bolt ook. Het verschil zit in wie de verantwoordelijkheid voor het draaiende geheel draagt.

Bij ons hoef je nooit zelf te migreren, te deployen of een .env bij te werken. Dat doen wij, het zit in Hosting Compleet. En besluit je ooit weg te gaan, dan dragen we de repository netjes over, inclusief uitleg over de koppelingen die erin zitten. Geen gesloten systeem, maar ook geen ZIP-bestand waar je het zelf maar mee moet uitzoeken.

Veelgestelde vragen

Krijg ik bij Lovable echt mijn complete code?expand_more

Ja. Lovable synct je codebase naar je eigen GitHub-repository, inclusief database-schema en RLS-policies. Wat niet automatisch meekomt is de database-inhoud, de auth-configuratie, de storage-bestanden en de omgevingsvariabelen. Die migreer je apart.

Kan ik een Bolt-site zonder Bolt draaien?expand_more

Ja. Je downloadt het project als ZIP of synct naar GitHub, draait npm install lokaal en deployt naar Netlify, Vercel of een eigen server. Heeft je app een database, dan moet je de data apart overzetten, want alleen de structuur wordt gekopieerd.

Heb ik een developer nodig om te migreren?expand_more

In de praktijk wel, zodra je site meer is dan een paar statische pagina’s. Het schema, de data, de auth en de hosting overzetten vraagt technische kennis. Er zijn tools die delen automatiseren, maar het blijft een traject dat je wilt testen voor je live gaat.

Is dit anders dan bij WordPress?expand_more

Deels. Een WordPress-migratie is een ingesleten proces met kant-en-klare plugins en duizenden hostingproviders die het ondersteunen. Een Lovable- of Bolt-migratie is technisch goed mogelijk, maar minder gestandaardiseerd, dus je leunt meer op handwerk of een specialist.

Wat als ik nu al op Lovable of Bolt zit en twijfel?expand_more

Begin met de twee kernvragen: heb ik de code in een eigen GitHub-repo, en weet ik welke externe diensten (Supabase, betaalprovider, mailserver) erin verweven zitten? Met die twee antwoorden weet je hoe groot een eventuele verhuizing wordt. Wil je het laten beoordelen, stuur ons gerust een bericht.