Een product met AI gebouwd: zo verbeter je het veilig na de lancering

Lees meer over werken met modellen in de Ailoot-documentatie.

Waarom begint het duurste werk na de lancering?#

Je bouwde op een avond een app, publiceerde een link en stuurde die naar je vrienden. Hij werkt. Een week later komt de eerste echte gebruiker langs, klikt iets op de verkeerde manier aan en de helft van de functies werkt niet meer. Je vraagt Claude om het op te lossen—hij repareert één ding en breekt iets anders. Komt dat bekend voor?

En dan komt de belangrijkste vraag op: wat doe je nadat je een product hebt gelanceerd, zodra de euforie van het eerste werkende prototype voorbij is en je het toch op de een of andere manier moet onderhouden? Je zou dit vibe coding voor volwassenen kunnen noemen. Bouwen draait om enthousiasme en snelheid. Onderhoud vraagt om een koel hoofd: je begrijpt wat je verandert en houdt het onder controle. De meeste mensen falen in dit tweede deel omdat niemand ze erop voorbereidt.

Een branchestudie analyseerde meer dan een miljoen codewijzigingen van 2.444 teams en berekende waar het geld dat aan AI-ontwikkeling wordt besteed daadwerkelijk naartoe gaat. Dit is het beeld:

De gids “De verborgen kosten van vibe coding” legt deze cijfers uitgebreider uit. Daar ging het om waar je voor betaalt. Hier is de vraag anders: 44 cent van elke dollar gaat naar het oplossen van bugs—en dit hele artikel gaat over voorkomen dat dat aandeel groeit. Het werk om dat onder controle te houden heet onderhoud.

Het verschil tussen iemand die aan vibe coding doet als een volwassene en iemand die alleen maar een neuraal netwerk babysit, wordt na de lancering zichtbaar. De codebasis van de eerste groeit, diegene brengt verbeteringen aan en er gaat niets kapot. Een maand later is het product van de tweede veranderd in een lekkend bouwsel dat diegene niet meer durft aan te raken. Hieronder leg ik uit hoe je bij de eerste groep terechtkomt.

Wat gaat er daadwerkelijk mis: 5 rampen na de lancering#

Dit zijn openbare postmortems van echte producten die met AI zijn gebouwd, met cijfers en datums. Zie ze als een kaart van een mijnenveld—elke mijn is bij iemand al afgegaan en de route eromheen is bekend.

Alle vijf hebben dezelfde grondoorzaak. Standaard zorgt AI ervoor dat dingen nu werken, niet dat ze over een maand onder belasting veilig werken. Tijdens het ontwikkelen op je computer zie je het verschil niet. Het wordt duidelijk wanneer de eerste onbekende met slechte bedoelingen opduikt.

Het probleem is niet dat je de code niet met de hand schrijft—veel mensen werken zo. Het probleem is dat niemand vraagt: “Is de database beveiligd?” Hieronder laat ik een prompt zien die deze vraag voor je stelt.

Het eerste vangnet is git en teruggaan naar “hoe het gisteren was”#

Wanneer Claude iets stukmaakt, heb je een knop nodig om “het terug te zetten zoals het gisteren was”. Technisch heet die knop git, en het is eenvoudiger dan het klinkt.

Drie termen die een niet-programmeur moet begrijpen:

1. Repository — je projectmap die in de cloud is opgeslagen (meestal op GitHub). Een kopie van al je code die niet alleen op je computer staat.
2. Commit — een terugkeerpunt. Je zegt eigenlijk tegen de code: “sla deze staat op”. Elke commit is een markering waarnaar je kunt terugkeren.
3. Deploy — een verplaatsing. De code stond lokaal op je computer en werkte alleen voor jou. Deploy stuurt die naar een externe server, zodat hij voor iedereen werkt.

Zolang je recente commitpunten hebt, kun je elke storing met één zin terugdraaien. Letterlijk.

Ik heb iets stukgemaakt—gisteren werkte alles, maar vandaag niet meer. Zoek de laatste commit waarop alles goed werkte, laat zien wat er sindsdien is veranderd en zet het project terug naar die staat.

Twee regels die je meteen moet invoeren, voordat anderen het product zien:

• De repository moet privé zijn. Niet openbaar. Anders kan iedereen je code en alles wat erin staat lezen.
• Zet het bestand met geheimen op de negeerlijst. Sleutels, wachtwoorden en inloggegevens voor de database staan in een apart bestand (meestal .env), en dat bestand komt nooit in de repository terecht. Voeg een regel voor .env toe aan .gitignore en de geheimen blijven bij jou.

Er is een aparte gids over wijzigingen veilig terugzetten in Claude Code: Wijzigingen terugzetten in Claude Code. Zonder terugkeermomenten loop je over een koord zonder vangnet en vroeg of laat val je.

Wat zet /rewind terug, en wat niet?#

Claude Code maakt een snapshot van de toestand vóór elke wijziging die het aanbrengt. De opdracht /rewind (of twee keer op Esc drukken) zet zowel bestanden als het gesprek terug naar een geselecteerd punt. Handig: als je vijf minuten geleden een functie kapotmaakte, kun je vijf minuten teruggaan.

Maar er is een valkuil waardoor beginners gegevens verliezen. /rewind draait niet alles terug:

Anthropic zegt het zelf duidelijk: snapshots zijn een lokale knop om iets ongedaan te maken, terwijl git de permanente geschiedenis is. Snapshots vullen versiebeheer aan, maar vervangen het niet.

De praktische conclusie voor een niet-programmeur: /rewind redt je van “Claude heeft net een functie kapotgemaakt”. Maar als het een database-record heeft verwijderd of code naar de cloud heeft geüpload, kunnen alleen git en een databaseback-up het terugbrengen. Houd dus beide lagen: snapshots om snel terug te draaien, commits voor de permanente projectgeschiedenis.

Hoe verbeter je dingen zonder te breken wat al werkt?#

Elke tweede persoon komt in deze lus terecht. Je vraagt AI een kleine bug op te lossen. Het stelt een redelijke wijziging voor. Die wijziging breekt iets anders. Je vraagt het nieuwe probleem op te lossen en er verschijnen nog twee problemen. En zo verder.

De lus ontstaat doordat vibe coding niet-deterministisch is. Dezelfde prompt levert twee keer verschillende code op. Elke bewerking kan dus ongemerkt de omliggende logica verschuiven: de kortingsdrempel gaat van 10 naar 12 procent, of een validatieregel gaat zich anders gedragen—zonder dat je iets controleert en zonder ook maar één waarschuwing. Dit heet logische drift en beschadigt ongemerkt precies de dingen die geld opleveren: prijzen, toegang en betalingen.

Er is één regel tegen drift, eenvoudig genoeg om aan de muur te hangen: commit geen code die je niet woord voor woord aan iemand anders kunt uitleggen.

In de praktijk wordt dit een kant-en-klaar sjabloon dat je vóór elke wijziging aan werkende code kunt gebruiken. Het laat AI kleine stappen zetten en precies laten zien wat er is veranderd.

Doe het volgende voordat je de code wijzigt:

Sla de huidige werkende staat op als een apart terugkeerpunt (commit).

Beschrijf in woorden precies wat je van plan bent te wijzigen en in welke bestanden.

Breng de kleinst mogelijke wijziging aan—alleen wat mijn taak oplost, niets extra's.

Laat me zien wat er is veranderd en leg elke wijziging zo uit dat ik die aan iemand anders kan uitleggen.
Raak de prijsstelling, toegang of betalingslogica niet aan tenzij ik daarom heb gevraagd.

Een ander principe dat weken bespaart, is discipline rond de grenzen van een taak. Eén pijnpunt, één wijziging, snelle uitvoering. Vraag AI niet in één prompt de helft van het project te herschrijven. Professionele ontwikkelaars beginnen soms een complete Uber te bouwen terwijl ze maar één knop nodig hadden—en zijn daar maanden mee bezig. Dat hoeft voor jou niet.

Alles wat ik beschrijf steunt op één ding: context beheren. Om te voorkomen dat AI aangrenzende logica breekt, moet het de regels van je project onthouden.

Hoe controleer je een wijziging voordat je die publiceert?#

Tussen “het werkt op mijn computer” en “het werkt voor iedereen” zit een tussenstap die beginners overslaan: een testkopie. Dat is een aparte momentopname van je productieomgeving waarop je een wijziging controleert voordat echte mensen die zien. De werkcyclus ziet er zo uit:

1. Bouw en controleer de wijziging zelf (development).
2. Deploy die naar staging—een kopie van productie, maar zonder echte gebruikers.
3. Doorloop de belangrijkste scenario's en controleer of niets is veranderd.
4. Deploy die pas nu naar productie.

Waarom dit na de lancering belangrijk is: elke release brengt risico met zich mee. Een kleine codewijziging kan het aanmelden bij een account breken. Eén ontbrekende instelling kan het hele product stilleggen. Staging vangt deze problemen op zonder gevolgen; in productie verlies je klanten.

Om te voorkomen dat je elke keer alles handmatig moet controleren, geef je AI een prompt om het gedrag van de nieuwe versie op de kritieke punten met dat van de oude versie te vergelijken.

Ik sta op het punt een wijziging te deployen. Doorloop de belangrijkste scenario's van het product in deze volgorde en controleer of elk scenario nog werkt zoals voorheen:

Registratie en aanmelding van een nieuwe gebruiker.

Betaling en toegang verlenen na betaling.

Toegangsrechten—een gewone gebruiker kan de gegevens van iemand anders of het beheerdersgedeelte niet zien.

Belangrijke cijfers van de bedrijfslogica (prijzen, kortingen, limieten) zijn niet veranderd.
Als iets zich anders gedraagt dan in de vorige versie, stop dan en laat me precies zien wat er is veranderd.

Waar staan je geheimen? Het grootste gat van een beginner#

Ik leg de grootste landmijn uitgebreid uit omdat die meer producten uitschakelt dan welke andere ook. Wanneer AI code schrijft, is het makkelijkste om een sleutel op de plek te zetten waar die meteen werkt—rechtstreeks in de code voor de pagina die in de browser wordt geopend. Tijdens de ontwikkeling merk je het verschil niet. Maar iedereen kan alles lezen wat de browser bereikt door de ontwikkelaarstools te openen.

De oprichter van wie de klanten voor $87,500 werden belast, zei later dat één prompt dit had kunnen voorkomen. De kosten werden uiteindelijk teruggedraaid, maar de niet-terugbetaalbare kosten en het verlies van gemoedsrust bleven. Dit is die prompt.

Controleer het hele project en zorg ervoor dat er geen geheime sleutel in de browser terechtkomt:

Zoek alle sleutels voor de database, het betalingssysteem en externe services.

Zorg ervoor dat elke sleutel alleen op de server in omgevingsvariabelen wordt opgeslagen en niet in de paginacode staat.

Controleer de projectgeschiedenis—staat er misschien eerder per ongeluk een sleutel in?
Laat me een lijst zien van elke plek waar je geheimen hebt gevonden en wat er per plek moet gebeuren.

Een nabije landmijn is het controleren van toegangsrechten alleen aan de browserkant. Als je product in paginacode beslist of het “het beheerdersgedeelte toont”, kan iedereen die beslissing omzeilen. Toegangsrechten moeten altijd op de server worden gecontroleerd. De database mag gegevens alleen teruggeven aan mensen die daartoe gerechtigd zijn—daarvoor dient row-level security (RLS), en die moet op elke tabel worden ingeschakeld.

Voer een algemene beveiligingsaudit van het product uit voordat je toegang verkoopt of anderen binnenlaat.

Loop het project door als een aanvaller en zoek beveiligingslekken:

Staan er geheime sleutels in code die naar de browser gaat of in de projectgeschiedenis?

Is row-level security (RLS) ingeschakeld op elke databasetabel, en worden toegangsrechten op de server gecontroleerd in plaats van alleen in de browser?

Is er een automatische databaseback-up ingesteld, en heb ik ooit gecontroleerd of ik die kan terugzetten?

Is de productiedatabase geïsoleerd van de omgeving waarin de AI-agent draait?
Vertel me voor elk punt of alles in orde is of precies wat er moet worden opgelost.

Er is een aparte, volledige gids over beveiliging bij vibe coding: Een met vibe coding gebouwde app beveiligen. De regel is eenvoudig: ga ervan uit dat alles wat AI standaard heeft gedaan onbeveiligd is, totdat je het tegendeel hebt gecontroleerd.

Waar host je je product: de hostingladder#

Je hoeft niet meteen een eigen server te huren en die handmatig te configureren—dat is in het begin een ingewikkelde taak en kost je tijd. Er is een ladder die je kunt beklimmen wanneer het product groeit:

1. Gratis hosting (bijvoorbeeld Vercel)—voor jezelf, tests en kleine projecten. Het werkt als het platform beschikbaar is voor je doelgroep en je geen persoonsgegevens opslaat.
2. Een platform waarop je met één opdracht kunt deployen (Railway)—wanneer je een backend en een database hebt. Je deployt met één opdracht en hoeft geen server te configureren. De drempel om te beginnen is minimaal.
3. Je eigen dedicated server—wanneer de belasting hoog is en je volledige controle nodig hebt. Stap later over wanneer je de limiet van het platform hebt bereikt.

Voor een niet-programmeur die net een product heeft gelanceerd, is een platform waarop je met één opdracht kunt deployen de makkelijkste optie, zonder handmatige serverconfiguratie. Stap later over op je eigen server. Als je dit pad met een concreet voorbeeld wilt volgen, bekijk dan de gids over een met vibe coding gebouwd project met Coolify op je eigen server deployen.

Wanneer moet je de app, database en back-ups scheiden?#

Drie dingen moet je niet in één mandje bewaren: de app, de database en back-ups. Zolang er weinig gebruikers zijn, staat alles bij elkaar en dat is prima. Maar er is een duidelijk signaal dat het tijd is om ze te scheiden.

• Zet de app en database op verschillende machines. Het signaal: bij piekbelasting blijven CPU- en geheugengebruik boven 70–80 procent, worden verzoeken trager en strijden de app en database om dezelfde resources. Nadat je ze hebt gescheiden, kun je de database versterken zonder de app aan te raken, en andersom.
• Volg de 3-2-1-regel voor back-ups. Drie kopieën van de gegevens, op twee verschillende soorten media, waarvan één off-site. Dit beschermt tegen hardwarestoringen en ransomware. Het belangrijkste is dat back-ups automatisch worden gemaakt.

De frequentie van back-ups hangt af van hoe duur het is om gegevens van meerdere uren te verliezen. Voor een online abonnementsdienst waarbij een uur betaalregistraties verliezen onaanvaardbaar is, moet de back-upinterval korter dan een uur zijn, of zijn gecontroleerde transactielogs en herstel naar een tijdstip (PITR) nodig. Kies de interval op basis van maximaal aanvaardbaar gegevensverlies en test apart hoeveel tijd herstel van de dienst kost. Eén keer per dag is genoeg voor een blog. De logica is eenvoudig: bepaal hoeveel gegevens je je kunt veroorloven te verliezen en configureer de back-ups daarop.

Help me bepalen of het tijd is dat mijn product naar een serieuzere infrastructuur overstapt. Controleer elk punt en stel me er vragen over:

Hoe zwaar worden CPU en geheugen belast bij piekbelasting—blijft het gebruik boven 70–80 procent of niet?

Staan de database en app op dezelfde machine of op verschillende machines?

Is er een automatische databaseback-up ingesteld, en heb ik het terugzetten daarvan getest?

Is er een aparte kopie van de omgeving (staging) om wijzigingen vóór deployment te controleren?
Geef op basis van de resultaten een duidelijke aanbeveling: wat kan blijven zoals het is, wat moet je als eerste scheiden en waarom.

Er is nog een aparte vraag: een beheerde database of je eigen database. Voor een klein team is een beheerde database bijna altijd beter: je eigen database is goedkoper qua hardware, maar kost uren aan onderhoud. Als je alleen werkt en je product geen infrastructuur is, kosten die uren meer dan het verschil in serverprijs.

Hoe automatiseer je het onderhoud?#

Handmatig onderhoud is vermoeiend. Je kunt het op twee manieren uit handen geven: monitoring en een patrouille-agent.

Monitoring gebruikt twee verschillende hulpmiddelen voor twee verschillende taken:

1. “Is de site bereikbaar?”—een uptime-monitor (bijvoorbeeld UptimeRobot). Die controleert het product elke paar minuten en stuurt een melding als het uitvalt. Er is een gratis abonnement.
2. “Wat is er precies kapot?”—een foutentracker (bijvoorbeeld Sentry). Die verzamelt fouten in de app en laat zien waar en waarom iets is misgegaan.

De eerste merkt op dat het product is uitgevallen. De tweede laat zien welke functie faalde en waarom. Samen beantwoorden ze de vraag: “Kom ik erachter dat er iets mis is voordat een klant de klantenservice schrijft?”

Het tweede automatiseringsniveau is een patrouille-agent. Stel je een makelaarskantoor voor: om zeven uur 's ochtends leest een AI-agent aanvragen op de website, ziet dat het boekingsformulier kapot is, vindt de oorzaak in de code en levert je een kant-en-klare oplossing met uitleg. Je controleert die en zegt “ja”—dan wordt die gedeployed. De volgorde is belangrijk: los eerst het probleem van de gebruiker op (verleen toegang, bied excuses aan) en onderzoek daarna de oorzaak en het geld.

Nog een regel over AI-toegang tot de productiedatabase: geef de AI een gebruiker met alleen-lezenrechten en verberg persoonsgegevens achter een tussenlaag, zodat de agent “naam” ziet in plaats van de echte naam van iemand. Dan kan die, zelfs als hij een fout maakt, de productiegegevens fysiek niet verwijderen of beschadigen. Het incident uit de tabel hierboven, waarin een agent de productiedatabase wist, gaat precies over het ontbreken van deze beperking. De gids Wat moet je doen als AI je database heeft verwijderd legt uit wat je moet doen als de ramp al heeft plaatsgevonden.

Wanneer is het tijd om een product stop te zetten?#

Het meest onderschatte deel van onderhoud is weten wanneer je ermee moet stoppen. Iedereen die veel bouwt, heeft een kerkhof van projecten: er een gebouwd, eraan gesleuteld en het toen verlaten. Dat is normaal en geen mislukking. Het is een mislukking om iets dat niemand gebruikt maandenlang mee te slepen uit spijt over de tijd die je erin hebt gestoken.

Drempels die je kunt gebruiken om de beslissing te nemen:

1. Twee weken—genoeg om te zien of een idee werkt. Als de eerste echte gebruikers terugkomen, ga dan door. Stilte is ook een antwoord.
2. Drie maanden—de harde grens. Als het in drie maanden niet van de grond komt, stop er dan mee. Met de snelheid van vibe coding is zes maanden besteden aan het testen van één idee te lang.

Een project sluiten is psychologisch moeilijk, dus behandel het als een beslissing en niet als een gevoel. Een project waarin je hebt geïnvesteerd loslaten is als een werknemer ontslaan die het werk niet kan doen: onaangenaam, maar hem houden kost meer dan hem laten gaan.

Onderhoud is werk dat ervoor zorgt dat een product blijft bestaan en nuttig blijft voor mensen. Al het andere—git, back-ups, monitoring—is alleen gereedschap om het punt te bereiken waarop het product elke dag voor jou gaat werken.

Een product in één avond met AI bouwen is de helft van het werk. Het product in leven en veilig houden naarmate het groeit—dat is wat vibe coding voor volwassenen betekent.

Voor je volgende stap—Ailoot.