Van v0 naar een echte site

Wat heb je na v0 in handen, en wat ontbreekt er nog?

Je hebt broncode van interface-onderdelen: een knop, een formulier, een heel scherm. Dat is de laag die je bezoeker ziet, en de laag waarvan je het snelst iets hebt dat er af uitziet. Daar zit ook de verwarring: een scherm dat af oogt voelt als een product, terwijl het nog geen enkele handeling van een bezoeker bewaart.

Wat ontbreekt is niet het ontwerp maar het geraamte eromheen. Een project dat de onderdelen bij elkaar houdt en dat gebouwd kan worden. Adressen, zodat elke pagina een eigen URL heeft. Echte data, want de voorbeeldgegevens in een component komen straks ergens vandaan. Een ontvanger voor je formulieren, want een verzendknop die nergens heen gaat is een tekening van een verzendknop. En de dingen die niets met uiterlijk te maken hebben: hosting, domein, database, geheimen, back-ups.

Het goede nieuws: dat is een lijst, en een lijst kun je aflopen. Niets erop is moeilijk. Alles erop is onzichtbaar zolang niemand het je vertelt.

• Wat je hebt: broncode van schermen en componenten, in de conventies van het framework waarvoor ze gemaakt zijn.
• Wat er nog moet: een project eromheen, adressen per pagina, echte data, een ontvanger voor formulieren.
• Wat los van het uiterlijk staat: hosting, domein, database, geheimen, back-ups.
• Wat je niet hoeft: alles tegelijk. Kies per stap de kleinste versie die goed genoeg is.

Hoe krijg je je componenten uit v0 en in je eigen project?

Een component is gewone broncode, en broncode neem je mee. In de praktijk zijn er twee routes: je haalt de code van een onderdeel op en plakt hem in een project dat je zelf beheert, of je laat de code in een codeopslag landen waar jouw project uit put. Welke routes v0 vandaag aanbiedt en hoe je ze start, zoek je op in de documentatie van v0 bij export en versiebeheer. Neem die als bron, niet een blogbericht van een half jaar geleden.

Belangrijker dan de route is de ontvangende kant. Zorg dat je eerst een leeg, werkend project hebt dat je kunt bouwen. Controleer daarna per component vier dingen. Draait het project op hetzelfde framework en dezelfde grote versie? Gebruikt het dezelfde stijlconventie? Zijn de afhankelijkheden waar het component om vraagt geïnstalleerd? En kloppen de paden van de imports? Een component dat om een icoonset of een componentenbibliotheek vraagt die er niet is, laat je project niet bouwen. Dat is een van de weinige foutmeldingen in dit traject die je meteen krijgt, en dus een cadeautje.

Werk daarna per scherm en bouw tussendoor, zodat je altijd weet welke stap iets brak. Houd bij wat je hebt overgenomen en wat je zelf hebt aangepast, want zodra je in de tool doorwerkt bestaan er twee versies van hetzelfde scherm.

• Zoek in de documentatie van v0 op welke exportroutes er zijn en volg die boven elke algemene uitleg.
• Begin met een leeg project dat aantoonbaar bouwt, en plak daar pas in.
• Controleer framework, versie, stijlconventie en afhankelijkheden voordat je plakt.
• Neem één scherm per keer over en bouw tussendoor.
• Houd bij wat je zelf veranderde, anders overschrijf je het bij de volgende ronde.

Waar host je je project en hoe koppel je je domein?

Een project met componenten is meestal geen map met kant-en-klare bestanden maar iets dat eerst gebouwd moet worden. Je zoekt dus een host die je code bouwt en uitrolt, niet alleen een plek die bestanden uitlevert. v0 is van Vercel, dus hosting bij Vercel ligt dichtbij. Dat is een feit over afstand en geen aanbeveling: elke host die jouw framework kan bouwen en draaien is even goed een kandidaat, en je vergelijkt ze op dezelfde vier eisen.

Die vier: kun je je eigen domein koppelen, krijg je automatisch HTTPS, kun je omgevingsvariabelen instellen zonder ze in je code te zetten, en kun je weg zonder alles te herbouwen. Dat laatste wordt het vaakst vergeten en telt het zwaarst. Een host die je code als gewone code behandelt, kun je verlaten.

Het domein zelf is één keer werk. Je koopt de naam bij een registrar en zet twee soorten records klaar: een A-record dat je kale naam aan een adres knoopt en een CNAME voor een subdomein zoals www. Je host geeft je meestal precies op wat er moet staan, en die instructie gaat boven elke algemene uitleg. Reken op minuten tot uren voordat een wijziging overal zichtbaar is, kies één vorm als de echte en verwijs de andere daarheen door, en zet HTTPS aan voordat je de link deelt.

• Kies een host die bouwt en uitrolt, niet alleen bestanden uitlevert.
• Vier eisen: eigen domein, automatisch HTTPS, omgevingsvariabelen, en een uitweg.
• A-record voor de kale naam, CNAME voor www, en de instructie van je host is leidend.
• Eén canonieke vorm, de andere doorverwijzen; wacht op de TTL voordat je concludeert dat het stuk is.
• Prijzen en gratis lagen veranderen snel, dus staan ze niet in deze gids: kijk op de officiële prijspagina van v0 en op die van de host die je kiest.

Hosting en domein staan uitgebreider in de hoofdgids: welke hosting kies je en hoe koppel je een domein.

Wat doe je met je database en je geheimen?

Een interface heeft geen geheugen. Zodra een bezoeker iets opslaat heb je een database nodig, en zodra je project met een andere dienst praat heb je sleutels. Dit zijn de twee onderwerpen die het langst blijven liggen omdat je ze niet ziet, en het zijn allebei kleine klussen zolang je ze op tijd doet.

Voor de database is een beheerde relationele database de veilige standaardkeuze: iemand anders doet de updates en de back-ups, en het formaat is niet van één aanbieder, dus je kunt weg. Zet die back-up aan en herstel er één keer echt uit, want een back-up die je nooit hebt teruggezet is een aanname. Houd je schema in migraties bij zodat je kunt zien wat wanneer veranderde. En sla alleen op wat je gebruikt: elk veld dat je niet bewaart, kan niet uitlekken.

Geheimen horen in omgevingsvariabelen bij je host, nooit in de code. Lokaal gebruik je een .env die buiten versiebeheer blijft, met ernaast een .env.example die alleen de namen bevat. Let bij een project met een voorkant extra op het verschil tussen sleutels die de browser mag zien en sleutels die alleen op de server bestaan. De meeste frameworks markeren met een voorvoegsel in de naam welke variabelen meegaan naar de browser. Zoek in de documentatie van jouw framework op welk voorvoegsel dat is, en ga ervan uit dat alles wat de browser kan ophalen publiek is. Is er ooit een sleutel gelekt, dan wissel je hem, want verwijderen uit de code trekt de oude waarde niet in.

• Beheerde relationele database, back-up aan, en één echte herstelproef.
• Schema in migraties, en sla alleen op wat je echt gebruikt.
• Geheimen in omgevingsvariabelen bij de host; .env buiten versiebeheer.
• Zoek het voorvoegsel voor publieke variabelen op in de documentatie van je framework.
• Een gelekte sleutel wissel je, verwijderen is niet genoeg.

Uitgebreider in de hoofdgids: wat doe je met je database en waar laat je je geheimen.

Welke checks doe je vóór livegang?

Voor livegang loop je één ronde die je serieus doet en daarna herhaalt. De volledige lijst staat in de gezondheidscheck van basestep: achttien punten in vijf gebieden die je zelf aflegt en zelf afvinkt. Het platform kijkt niet mee en controleert je site niet automatisch; het geeft je de lijst en de uitleg, jij doet de handeling.

Bij een project dat bij de interface begon zijn er een paar checks die er extra uitspringen. Haal alle voorbeeldgegevens eruit, want een dashboard met verzonnen getallen op een echte site is een belofte die je niet waarmaakt. Controleer dat elk formulier echt aankomt en dat de invoer op de server wordt gecontroleerd, niet alleen in de browser. Loop de toestanden buiten het gelukkige pad langs: leeg, aan het laden, en mislukt. En doe de ronde die toegankelijkheid en vindbaarheid tegelijk afvinkt, want dat is hetzelfde werk: één h1 per pagina, kopniveaus in volgorde, alt-teksten, bruikbaar met het toetsenbord, zichtbare focus, genoeg contrast, en een eigen titel en beschrijving per pagina.

• Voorbeeldgegevens eruit voordat je de link deelt.
• Formulieren komen aan en worden op de server gevalideerd.
• Lege, ladende en mislukte toestanden bestaan en zien er verzorgd uit.
• Eén h1, kopniveaus in volgorde, alt-teksten, toetsenbord en contrast.
• HTTPS afgedwongen, een nette 404, en geen fouten in de console.

De achttien punten staan in de gezondheidscheck; de bredere ronde staat in de hoofdgids.

Wat blijft v0 voor je doen, en wat ligt bij jou?

v0 blijft een prettige plek om interface te bedenken en te herzien. Daar is de tool voor gemaakt, en dat verandert niet doordat jouw project ergens anders draait. De grens is simpel te onthouden: zodra code in jouw project staat, is jouw versie de waarheid.

Praktisch betekent dat het volgende. Een nieuw scherm bedenken in de tool mag altijd, maar je neemt het gericht over in plaats van dat je een map overschrijft. Wat jij zelf hebt aangepast, staat alleen in jouw project, en dus houd je dat bij. Het bouwen, het uitrollen en het draaiend houden liggen bij jou en bij je host. Afhankelijkheden bijwerken doe je op een vast moment, want een half jaar niets doen maakt van elke update een verbouwing.

En bij basestep ligt de begeleiding, niet de handeling. Het platform hijst je project niet online en controleert niet of je site draait. Het geeft je het pad in vier fasen, de gezondheidscheck om zelf af te vinken, en de administratie die klaarstaat zodra je verdient. Wat je bouwt blijft van jou en staat waar jij het zet.

• Bij v0: interface bedenken en herzien.
• Bij jou: het project, het bouwen, het uitrollen en het onderhoud.
• Neem nieuwe schermen gericht over; overschrijf nooit blind wat je zelf aanpaste.
• Vast moment voor updates, en maandelijks kijken of alles nog draait en aankomt.

Wat als je project geld gaat verdienen?

Zodra er geld binnenkomt verandert je project van iets dat werkt in een onderneming met verplichtingen. Er komt een administratie bij: facturen die aan eisen voldoen, btw die per periode klopt, een bewaarplicht voor wat je vastlegt, en een aangifte waar jij zelf je naam onder zet. Dat is precies waar basestep verder loopt dan deze gids, want het pad houdt niet op bij livegang: het loopt door van eerste prompt tot eerste aangifte, met een belastingmotor die elke rubriek uitlegt tot aan de wetsverwijzing. Regel het voordat het kwartaal om is, want een administratie die je achteraf reconstrueert kost meer tijd dan een administratie die meeloopt.

Dit is algemene uitleg, geen fiscaal of juridisch advies. basestep rekent en legt uit; jij dient zelf in.

Zo werkt het bij v0 in augustus 2026

De rest van deze gids is met opzet tijdloos geschreven. Deze sectie is dat niet. Hier staat wat vandaag waar is en over een paar maanden anders kan zijn, nagelezen op 30 augustus 2026 in de documentatie van v0 en van Next.js zelf. Lees het als startpunt, en controleer bij de bron voordat je iets onomkeerbaars doet.

Het exportmodel is gekanteld, en dat is het belangrijkste nieuws. Sinds februari 2026 draait v0 om projecten in plaats van om losse onderdelen: je repository is de bron van waarheid, en v0 bewaart daarnaast geen eigen kopie van je code. Elk bericht dat iets aan de code verandert wordt vastgelegd op een werkbranch, en samenvoegen doe je met een pull request. De oude gewoonte om een onderdeel met de opdrachtregel van shadcn naar je project te halen, staat nergens meer als de aangewezen weg beschreven. Ook de documentatie is verhuisd: de oude adressen op vercel.com sturen je door naar v0.app.

• Je code staat dus al bij jou zodra je versiebeheer hebt gekoppeld. Een bestaande repository importeren kan sinds februari 2026 ook.
• Er is een gedocumenteerd adres in de programmeerkoppeling waarmee je de bestanden van een gesprek als archiefbestand ophaalt. In het scherm zelf bestaat zo'n knop ook, maar die staat in geen enkele officiële pagina beschreven.
• Je account bij v0 is je account bij Vercel. Deployments, domeinen en omgevingswaarden zijn daarmee geen dingen van v0 maar van Vercel, en je beheert ze daar.
• Omgevingswaarden komen niet mee in je repository en niet in een archiefbestand. Je zet ze met de hand over naar je eigen host. Bij een gekoppelde database haal je ze opnieuw bij die dienst op.
• Van de vier databasekoppelingen zijn er drie gewoon een eigen account bij een externe dienst, met een verbindingsreeks die meeverhuist. De opslagdienst van Vercel zelf is dat niet: die zit aan hun eigen programmeerkoppeling vast.
• Let op de dienst die sinds 25 augustus 2026 in beta staat en je app zonder sleutels aan andere diensten koppelt met kortlevende tokens. Dat is prettig, en het werkt alleen op de infrastructuur van Vercel. Leunt je project erop, dan draait het nergens anders.
• Op een gratis account staat er een merkje op je site dat je niet kunt uitzetten.

Tegen de gangbare aanname in: Next.js zelf hosten kost je geen functies. De eigen documentatie van Next.js, versie 16.3.3 en bijgewerkt op 25 augustus 2026, zegt dat een Node-server en een Docker-container alle functies ondersteunen. Alleen een volledig statische export is beperkt, want die kan niets wat een server nodig heeft. Wat je bij een verhuizing echt kwijtraakt zijn dus niet de mogelijkheden van het framework maar de dingen die aan Vercel vastzitten: hun opslagdienst, die nieuwe koppeldienst, het beheer van je omgevingswaarden en de voorvertoningen per branch.

Wat we niet hebben kunnen vaststellen: of de opdrachtregel van shadcn met een v0-adres nog werkt, welk abonnement een eigen domein vraagt, en wat er precies in het archiefbestand zit. Ga dat na voordat je erop rekent.