Van AI-prototype naar een product dat klanten kunnen vertrouwen
Een prototype bouwen met Lovable, Bolt of Replit gaat snel. Slaat het idee aan, dan werken er al gauw klanten mee, met hun eigen gegevens. Vanaf dat moment moet de app meer doen dan alleen werken: de gegevens van die klanten moeten goed afgeschermd zijn, en iemand moet de app blijven bijhouden.
Hoe veilig zijn apps die met vibe coding zijn gebouwd?
Bij vibe coding beschrijft iemand in gewone taal wat de app moet doen en schrijft een AI-tool de code. Of een buitenstaander bij de gegevens van klanten kan, is aan de app zelf niet te zien: die doet gewoon wat er gevraagd is.
Uit een scan van Reeve van apps die al online staan, blijkt dat zulke apps de gewone controles meestal doorstaan, maar dat de ernstige fouten in de database zitten. Bij 57 procent van de apps met een Supabase-database die Reeve kon controleren, kon een buitenstaander zonder wachtwoord minstens één tabel met gegevens uitlezen. Een uitgelekte hoofdsleutel van de database, waarmee iemand bij alle gegevens kan, kwam Reeve maar bij drie apps tegen.
ENISA, het Europese agentschap voor cyberbeveiliging, schrijft in een concept van zijn technisch advies over softwareontwikkeling met AI dat software die correct werkt daarmee nog niet veilig is.
Het onderhoud begint bij de eerste klant
Een app met echte gebruikers vraagt om gewoon, doorlopend werk: inloggen en rechten goed instellen, fouten oplossen die klanten melden, en de onderdelen waarop de app draait bijwerken wanneer er een beveiligingsupdate voor uitkomt. Van die updates komen er steeds meer, nu open source-projecten mede door AI veel meer beveiligingsmeldingen krijgen.
Ook grote organisaties gaan dit merken: volgens Tray.ai verwacht Gartner in een rapport van juni 2026 dat tegen 2028 drie op de tien ontwikkelteams flink onder druk staan door apps die collega’s buiten IT met vibe coding hebben gebouwd.
Wanneer moet het onderhoud geregeld zijn?
Het beste moment ligt vóór het eerste incident, en niet pas wanneer een klant meldt dat hij de gegevens van een ander kan zien. Een duidelijk teken dat het zover is: niemand in het bedrijf weet precies hoe de code in elkaar zit, omdat een AI-tool hem heeft geschreven. Wie dan een fout moet oplossen of een update moet doorvoeren, moet eerst uitzoeken hoe alles samenhangt, en dat gaat nu veel makkelijker dan straks, als een klant op een oplossing wacht.
Wie kan de app verder brengen?
Het werk moet liggen bij iemand die er verantwoordelijk voor is en er ook tijd voor heeft. Welke route daarvoor past, hangt af van wat er al in huis is.
Het eigen team
Een bedrijf met eigen developers kan het werk bij dat team leggen, als er naast de nieuwe functies ook echt tijd voor wordt vrijgemaakt.
Een freelancer
Een freelancer past bij een afgebakende klus, zoals een beveiligingscheck of het goed instellen van inloggen en rechten. Wel moet dan vooraf vaststaan wie de app na die klus bijhoudt.
Een softwarebureau
Een softwarebureau kan de app als project verbeteren of opnieuw opbouwen. Het werk dat daarna komt, hoort niet bij het project, tenzij het bureau het onderhoud er uitdrukkelijk bij neemt.
Een dedicated developer
Blijft het product groeien, met doorlopend werk aan nieuwe functies en onderhoud, dan past een dedicated developer: iemand die alleen aan dit product werkt en het daardoor goed leert kennen.
Bij Backstage IT kan een bedrijf met een dedicated developer werken, ook zonder eigen ontwikkelteam. Die developer leert de code van het prototype kennen, bouwt het uit tot een product en houdt het daarna bij, ook de beveiligingsupdates. Wat AI-tools opleveren, kijkt de developer zelf na. Het bedrijf houdt de regie over het werk en kan met één developer beginnen.
In een vrijblijvend gesprek van een half uur kijken we samen hoe je app nu in elkaar zit en welke route bij je past.
