Heb je met Lovable, Bolt, Claude Code of Cursor een app gemaakt die in een demo werkt, dan heb je de eerste vraag over je idee al beantwoord: kun je het tonen, laten aanklikken en uitleggen? Wat een demo niet bewijst, is dat je de app veilig kunt geven aan onbekenden die er echte gegevens en echt geld in steken. Tussen die twee staat bijna altijd hetzelfde korte lijstje: wie welke gegevens ziet, wat er gebeurt als een betaling of een e-mail mislukt, waar de gegevens staan en wie de accounts beheert. Sommige prototypes krijg je over die drempel. Andere bouw je goedkoper opnieuw, met het prototype als specificatie.

Waar die tools goed in zijn

AI-appbouwers zijn sterk in het deel van een product dat vroeger het traagst ging: van een idee schermen maken die mensen kunnen uitproberen. Een oprichter kan vandaag in een week een werkende flow voorleggen aan tien mogelijke klanten, zonder iemand aan te werven, en zien of ze het willen. Dat is veel waard. De meeste productideeën zou je precies zo moeten testen voor iemand er serieus geld in steekt.

Die tools maken ook echte code. Lovable zegt bijvoorbeeld dat de code die je maakt van jou is en laat je die synchroniseren met een GitHub-repository. Een prototype is dus niet per definitie wegwerpwerk. Of het de moeite waard is om te behouden, hangt af van wat erin zit.

Waar een prototype meestal misloopt

Wie welke gegevens kan lezen

Dit controleer je eerst. Veel apps die met AI gebouwd zijn, gebruiken Supabase als database en spreken die rechtstreeks vanuit de browser aan. Dat is alleen veilig als op elke tabel Row Level Security (RLS) aan staat, met regels die bepalen welke gebruiker welke rijen mag lezen en wijzigen. De documentatie van Supabase zegt zelf: zet RLS aan op elke tabel in een blootgesteld schema.

Ontbreekt dat, dan kan iedereen die de ontwikkelaarstools van zijn browser opent de database bevragen. In 2025 werd dat geregistreerd als CVE-2025-48757: onvoldoende beveiliging op rijniveau in apps die Lovable tot 15 april 2025 genereerde, liet bezoekers zonder login willekeurige tabellen lezen of beschrijven. Lovable betwist de CVE, omdat elke klant volgens Lovable zelf verantwoordelijk is voor de bescherming van de gegevens in zijn app. Wie er ook gelijk heeft over de verantwoordelijkheid, praktisch geldt voor elke tool hetzelfde: die regels horen bij je app, en ze zijn maar zo goed als de laatste keer dat iemand ze nalas.

Sleutels horen op hetzelfde lijstje. Een publieke sleutel (publishable key) in de browser is normaal. Een geheime sleutel daar niet: Supabase zegt nooit een geheime sleutel in de browser te gebruiken, en Stripe zegt API-sleutels en webhookgeheimen niet in te bouwen in broncode of in applicaties aan de kant van de klant.

Rollen en accounts

Een demo heeft meestal één soort gebruiker. Een product heeft er minstens twee: de klant en jij als beheerder. Vaak meer, zoals een bedrijfsaccount met collega's, of een klant en een leverancier die elkaars gegevens nooit mogen zien. Rollen achteraf toevoegen betekent dat je elk scherm en elke databaseregel opnieuw moet bekijken. Daarom is het de meest voorkomende reden waarom een prototype opnieuw gebouwd wordt.

Het datamodel en migraties

In een prototype verandert de structuur van de database telkens als je om een functie vraagt. Zodra echte klanten er gegevens in hebben, moet elke wijziging een migratie zijn die bewaart wat er al staat. Kijk of je project migratiebestanden heeft die beschrijven hoe de database aan zijn huidige vorm kwam, en of een veld met bedragen, datums of een status een duidelijk type en een duidelijke betekenis heeft. Zijn tabellen tientallen keren via prompts omgegooid, dan is een nieuw model ontwerpen vaak sneller dan het oude ontwarren.

Betalingen

Een testbetaling ontvangen is makkelijk. Een echte betaalflow moet ook omgaan met een geweigerde kaart, met de klant die het tabblad sluit voor de bevestigingspagina, met een terugbetaling en met een abonnement dat verlengt. Met Stripe betekent dat een verwerking aan de serverkant die de handtekening van elk event controleert voor ze iets als betaald markeert. Zet het prototype een veld "betaald" vanuit de browser op waar, dan moet het betaalgedeelte opnieuw.

E-mails

Bevestigingsmails, wachtwoordresets en facturen moeten aankomen. Sinds 1 februari 2024 eist Gmail van elke afzender authenticatie met SPF of DKIM, en wie meer dan 5.000 berichten per dag verstuurt, heeft SPF, DKIM en DMARC nodig. Dat betekent: versturen vanaf je eigen domein via een degelijke e-mailprovider, met DNS-records die jij beheert.

GDPR en waar de gegevens staan

Zodra je persoonsgegevens van echte mensen bewaart, geldt de GDPR voor jou, niet voor de tool. Elke dienst die die gegevens voor jou verwerkt (databasehosting, e-mailprovider, analytics) heeft een verwerkersovereenkomst volgens artikel 28 nodig, en een inbreuk in verband met persoonsgegevens meld je waar mogelijk binnen 72 uur nadat je ervan op de hoogte bent aan de toezichthoudende autoriteit (artikel 33). Kijk in welke regio je database draait: Supabase zet elk project in één primaire regio, en de lijst bevat EU-regio's zoals Frankfurt, Parijs en Ierland, naast Londen en Zürich, die buiten de EU liggen.

Fouten, tests en kosten

Een prototype faalt in stilte. Een product heeft foutmonitoring nodig, zodat jij een crash ziet voor een klant je mailt, en tests op de paar flows die er het meest toe doen: registreren, de kernflow en het deel dat geld ontvangt. Kijk ook hoe de backend gefactureerd wordt. Diensten die per gebruik rekenen, kosten weinig met tien gebruikers. Bekijk de prijspagina van elke dienst waarop je steunt en reken uit wat duizend actieve gebruikers zouden kosten, voor je je eigen klanten een prijs belooft.

App stores, als het een mobiele app wordt

Wil je een ingepakte webapp in de App Store zetten, lees dan eerst richtlijn 4.2 van Apple: een app moet meer zijn dan een herverpakte website. Beide stores eisen ook dat een app waarin gebruikers een account kunnen aanmaken, hen dat account ook laat verwijderen: in de app op iOS en op Google Play in de app en via een weblink.

Op wiens naam de accounts staan

Maak een lijst van elk account waarop het product steunt: de bouwer, de GitHub-repository, de database, de domeinnaam, Stripe, de e-mailprovider, de ontwikkelaarsaccounts bij Apple en Google. Elk daarvan hoort op naam van je onderneming te staan, met jouw e-mailadres als eigenaar. De code is maar een deel van het verhaal. De FAQ van Lovable zegt dat de database-export geen opgeslagen bestanden, Edge Function-code of geheimen bevat, en de hostinggids zegt dat alleen de database verhuizen authenticatie, opslag, realtime en Edge Functions niet meeneemt. Plan die apart als je ooit verhuist.

Behouden of opnieuw bouwen?

Het prototype is waarschijnlijk de moeite waard om te behouden als:

de code in een Git-repository staat die jij beheert, met een leesbare geschiedenis;
RLS (of een vergelijkbare controle aan de serverkant) aan staat op elke tabel, en de regels overeenkomen met wie wat mag zien;
de database migratiebestanden heeft en een structuur die je kunt uitleggen;
er geen geheime sleutels in de browsercode staan;
het de rollen die je nodig hebt al heeft, of het toevoegen ervan maar een klein deel raakt.

Opnieuw bouwen is meestal goedkoper als:

het datamodel door veel prompts is omgegooid en niemand nog weet waarvoor elke tabel dient;
je rollen of accounts voor meerdere bedrijven nodig hebt die het prototype nooit had;
betalingen vanuit de browser bevestigd worden;
elke nieuwe prompt iets breekt dat eerst werkte.

Opnieuw bouwen gooit het prototype niet weg. Het is de duidelijkste specificatie die een ontwikkelaar kan krijgen: de schermen, de flow en de keuzes die je al met gebruikers getest hebt. Vaak blijft er een deel van over, zoals de interfacecomponenten.

Hoe een overdracht aan een studio verloopt

Je geeft toegang tot de repository, het databaseproject en de accounts hierboven, met een korte notitie over wie de gebruikers zijn en wat ze moeten kunnen. De studio leest de code, laat ze draaien, controleert de punten uit dit artikel en zegt wat ze zou behouden, herstellen of vervangen, en tegen welke prijs. Daarna werkt ze het bestaande product af of bouwt ze de eerste echte versie van nul.

Wij doen allebei. Onze web-app-MVP (de eerste echte versie die klanten kunnen gebruiken) kost € 14.000 exclusief btw, in 8–10 weken: één kernflow, accounts en authenticatie, een eenvoudige beheeromgeving, één koppeling of betaalweg, tests op de kritieke flows, livegang, monitoring en documentatie, met de repository en de accounts op jouw naam. We starten met de webversie: native apps voor iOS en Android, extra koppelingen, extra talen en de overzetting van gegevens zijn uitbreidingen met een vaste prijs, die we vooraf offreren. De volledige lijst staat op de MVP-pagina en de prijspagina.

We nemen ook producten over die andere ontwikkelaars begonnen. Bij Getizy namen we een bestaande iOS- en Android-app over van het vorige ontwikkelbedrijf, losten we de geërfde bugs en technische schuld op en bleven we nieuwe functies uitbrengen in beide stores. De overname van een bestaande codebase begint bij ons met een betaalde review van de code, de Product Decision Sprint (€ 2.500, 5 werkdagen), die volledig verrekend wordt met een bouwproject dat binnen 30 dagen start. De offerte met vaste prijs volgt na die review, op basis van wat er echt in de repository staat. Overleg tijdens het project verloopt in het Engels of het Russisch.