Hoe je een back-up maakt van je met AI gebouwde app

Een oprichter met wie ik praat, runt zijn hele boekingsbedrijf — drie locaties, zo’n 200 klanten per week — op een app die hij zelf bouwde met een AI-appbouwer. Hij liet hem me op een dinsdag zien en was er erg trots op. Op woensdag vroeg hij me, een tikje nerveus: “Als dit ding stuk gaat, raak ik dan gewoon… alles kwijt?”

Het eerlijke antwoord was: misschien. Hangt af van wat je met “stuk gaat” bedoelt. Hangt af van wat voor back-up hij had (hij had er geen). Hangt af van of hij hem op tijd opnieuw kon maken.

Dat gesprek is het meest voorkomende dat ik heb met mensen die een app met AI hebben gebouwd. De build zelf voelt als een klein wonder. De vraag “wat gebeurt er als het verdwijnt” komt bijna nooit op totdat de app al echt werk doet — en tegen die tijd zijn de gevolgen van hem kwijtraken serieus geworden.

Deze post is voor iedereen die een echte, werkende app heeft gebouwd zonder hem zelf te coderen, en nu erop vertrouwt voor iets dat ertoe doet. We behandelen wat er echt op het spel staat, wat je moet back-uppen, hoe vaak, en wat je doet als er iets misgaat. Het is niet technisch. Er zijn geen scripts om uit te voeren. Het doel is ervoor te zorgen dat je, wat je ook hebt gebouwd, het niet kwijtraakt omdat niemand je vertelde dat back-ups een ding waren.

Wat er echt in je met AI gebouwde app zit (en wat kan verdwijnen)

Een met AI gebouwde app bestaat uit twee heel verschillende dingen, en je moet elk anders back-uppen.

Het eerste is de app zelf — de schermen, de logica, het ontwerp, de integraties. Dit is wat je AI-bouwer voor je genereerde. Het leeft in het account van je AI-bouwer, meestal binnen een project. Als je de toegang tot dat account verliest, of de bouwer heeft een storing, of het project raakt beschadigd, raak je dit kwijt.

Het tweede is je data — de gebruikers, de bestellingen, de berichten, de boekingen, de bestanden die mensen uploadden. Dit leeft meestal ergens in een database. Soms zit het in de AI-bouwer. Soms zit het in een dienst als Supabase, Firebase of Airtable. Soms is het verspreid over meerdere plekken.

Deze twee dingen hebben compleet verschillende risicoprofielen. De appstructuur verandert wanneer je de AI vraagt het te veranderen. Je data verandert elke keer dat een gebruiker iets doet. Dus ze hebben verschillende back-upstrategieën nodig.

Een nuttige manier om het te bekijken: als een gebouw zou afbranden, is de app de blauwdruk, en de data is wat er in het gebouw zat toen het afbrandde. Je kunt herbouwen vanaf de blauwdruk. Je kunt niet terugkrijgen wat erin zat.

Wat er op het spel staat: de vier scenario’s die echt gebeuren

Ik heb elk hiervan zien gebeuren bij mensen die met AI-appbouwers bouwen. Geen ervan is theoretisch.

1. Je vertelt de AI per ongeluk de app te breken. Je bent moe, je werkt om middernacht, en je zegt “verwijder de aanmeldpagina” omdat je hem wilt herontwerpen. De AI doet het. Hij verwijdert ook het deel van de app dat bestaande gebruikers laat inloggen. Nu kan niemand de app gebruiken, en de laatste werkende versie van de AI is weg tenzij je versiegeschiedenis aan hebt staan (veel bouwers hebben dat standaard niet).

2. De AI-bouwer heeft een storing of dataprobleem. Zeldzaam, maar echt. In 2024 had een populair no-codeplatform een storing van 6 uur waarbij klantdata ontoegankelijk was. Niemand verloor permanent data, maar veel bedrijven verloren een dag. Als je boekingsapp plat ligt op een zaterdagochtend wanneer je klanten zaterdagmiddag proberen te boeken, is dat geen “geen dataverlies” — dat is verloren omzet die je niet terugkrijgt.

3. Je account wordt vergrendeld. Misschien een factureringsprobleem, misschien een gemarkeerde login vanaf een nieuwe locatie, misschien een e-mailwijziging die niet doordrong. De app is in orde, je data is in orde, maar je kunt er niet in. Als je geen geëxporteerde kopie hebt, ben je overgeleverd aan de reactietijden van support.

4. Je verlaat het platform. Dit is degene waar mensen niet voor plannen. Over een jaar wil je misschien overstappen naar een andere tool, of een ontwikkelaar inhuren om over te nemen wat je bouwde. Als de enige kopie van je app en data binnen één bouwer leeft, zijn je opties smal en duur.

In elk van deze scenario’s is het verschil tussen “vervelend” en “catastrofaal” of je een back-up had.

Wat te back-uppen, en hoe vaak

Je hebt geen ingewikkeld systeem nodig. Je hebt een gewoonte nodig. Hier is het minimum dat ik aanraad voor iemand die met AI bouwt zonder code te schrijven.

Je data — elke dag, automatisch indien mogelijk.

Als je data leeft in iets als Supabase of Airtable, bieden beide geplande exports of back-ups. Zet dit aan. De meeste mensen slaan het over omdat het drie kliks is en ze denken dat ze het later wel doen. Doe het op de dag dat je lanceert.

Als je data binnen de AI-bouwer zelf leeft en er geen automatische export is, zet dan elke zondag een agenda-herinnering om het handmatig te exporteren. Exporteer het als een CSV per tabel. Bewaar het ergens buiten de bouwer — Google Drive, Dropbox, een externe harde schijf. Overal behalve dezelfde dienst.

Bewaar minstens vier weken van deze exports. Overschrijf niet elke keer hetzelfde bestand. Als je data op dinsdag beschadigd raakt en je het pas vrijdag merkt, wil je niet dat je enige back-up de al-kapotte data van vrijdag is.

Je appstructuur — elke keer dat je een belangrijke wijziging maakt.

De meeste AI-appbouwers hebben een vorm van versiegeschiedenis of snapshots. Vind deze functie. Gebruik hem. Voordat je een grote wijziging aan de app maakt — en “groot” betekent “iets dat je niet binnen een uur uit je hoofd opnieuw zou kunnen doen” — neem een benoemde snapshot. Noem hem iets nuttigs als “voor het toevoegen van betaalscherm” of “voor het veranderen van gebruikersrollen”.

Als je bouwer geen snapshots heeft, vraag de AI om in een lang document samen te vatten wat de app doet. Bewaar dat document. Het is geen echte back-up van de app, maar het is een recept — als het ergste gebeurt, kun je dat document als prompt gebruiken om te herbouwen.

Je accounts en inloggegevens — eenmalig, op de dag dat je lanceert.

Schrijf, op één plek, op waar alles leeft. Welk bouweraccount heeft de app. Welke databasedienst heeft de data. Welke e-mail is de beheerderslogin. Welke betalingsverwerker is gekoppeld. Welke integraties zijn gekoppeld.

Bewaar dit in een wachtwoordmanager, niet in een Google Doc. Als je morgen door een bus wordt aangereden, moet je zakenpartner dit allemaal kunnen vinden. Als je een solo-oprichter bent, moet je toekomstige zelf (zes maanden van nu, uitgeput, proberend te onthouden wat je bij de lancering deed) dit ook kunnen vinden.

Je bestanden — waar je gebruikers ook naartoe uploaden.

Als je app bestandsuploads accepteert — afbeeldingen, pdf’s, wat dan ook — leven die bestanden ergens. Vind waar. De meeste bouwers gebruiken een of andere opslagbucket. Check of die wordt geback-upt. Zo niet, stel dan een periodieke kopie naar je eigen opslag in.

Een simpele back-uproutine die ongeveer 20 minuten per week kost

Zondagavond, terwijl je toch al niet aan het werk bent:

Open je AI-bouwer. Neem een benoemde snapshot van de huidige appstatus. Dateer hem.
Exporteer elke datatabel als een CSV. Zet ze in een gedateerde map in je cloudopslag. (De meeste data leeft in 3–10 tabellen — geen enorm karwei.)
Werp een blik op je opslagbucket. Zorg dat er niets vreemds gebeurt (bestandsaantal dat explodeert, verdachte uploads).
Werk je “waar alles leeft”-document bij als er deze week iets veranderde.

Dat is het. Twintig minuten, eens per week. Het is wild buiten proportie verzekering voor wat het beschermt.

Als je dit niet handmatig wilt doen, kijk dan of je data ergens leeft met native back-up. Supabase, bijvoorbeeld, kan automatische dagelijkse back-ups voor je doen. Als je hun gratis laag gebruikt, zijn die back-ups beperkt; op een betaald abonnement gaan ze verder terug. Voor een bedrijf dat van de app afhangt, is dat betaalde abonnement de goedkoopste verzekering die je ooit zult kopen.

Wat te doen wanneer er iets misgaat

Als je app stuk gaat door een bug in de AI-bouwer of een slechte wijziging:

Prompt niet in paniek. De drang zal zijn om de AI te vragen het meteen te repareren. Verzet je hier tien minuten tegen. Een paniekfix in de verkeerde richting kan het erger maken, en de meeste bouwers maken een keten van prompts niet makkelijk ongedaan.
Rol terug naar je laatste snapshot. Als je er een hebt. Dit is de hele reden dat je hem nam.
Als je geen snapshot hebt, vraag de AI-bouwer om de laatste specifieke wijziging terug te draaien. Wees precies. “Maak de wijziging ongedaan waar we de aanmeldpagina verwijderden” is beter dan “laat het weer werken”.

Als je data beschadigd raakt:

Stop schrijfacties onmiddellijk. Haal de app offline als je kunt. Elke nieuwe gebruikersactie terwijl je data fout is, is meer data die je later moet verzoenen.
Herstel vanaf je meest recente goede back-up. Als je niet weet welke goed is, herstel ze één voor één naar een kopie van je omgeving totdat je de laatste schone versie vindt.
Verzoen wat er ontbreekt. Als je op vrijdag de back-up van zondag herstelt, ben je vijf dagen activiteit kwijt. Mail getroffen gebruikers, vraag ze te herhalen wat ze deden, en bied excuses aan. Mensen zijn verrassend begripvol wanneer je er eerlijk en snel over bent.

Als je de toegang tot je account verliest:

Neem onmiddellijk contact op met support. Probeer het niet “uit te zitten”. Supportwachtrijen van bouwers variëren; sommige zijn geweldig, sommige zijn traag.
Heb je identiteit klaarliggen. Oorspronkelijke aanmeld-e-mail, factureringskaartgegevens, de datum waarop je je aanmeldde, eventuele oude facturen. Accountherstel zonder deze is moeilijk.

Het ding dat niemand de oprichter vertelde

De boekingsoprichter waarmee ik begon, kocht een betaald abonnement voor zijn datadienst nadat we hadden gepraat. Hij stelde automatische dagelijkse back-ups in. Hij nam een snapshot van zijn app. Hij schreef al zijn accounts op in een wachtwoordmanager. Het hele ding kostte hem ongeveer een uur op een zondag.

Een maand later brak een AI-wijziging waar hij om vroeg per ongeluk zijn terugkerende boekingslogica. Klanten konden hun volgende afspraken niet zien. Hij merkte het binnen twintig minuten. Hij herstelde de snapshot in twee kliks. Hij behield de data, behield de app, en zijn klanten zagen nooit iets.

Hij vertelde me achteraf dat het het goedkoopste uur was dat hij ooit had besteed. Hij heeft geen ongelijk. Back-ups voor een met AI gebouwde app zijn ongeveer een uur instellen en twintig minuten per week aan gewoonte. Het ding waartegen ze beschermen, is het ding waarvan niemand die het kwijtraakte ooit dacht dat het hem zou overkomen.

Als je iets echts hebt gebouwd, neem vandaag een snapshot.