Een AI-prototype naar productie brengen

Om een AI-prototype naar productie te brengen, dicht je de kloof tussen „het werkt als ik het probeer” en „het blijft werken als anderen het gebruiken”. In de praktijk gaat het om vijf dingen: test de belangrijkste flows elke keer dat je iets verandert, zet vast wie wat mag zien en wijzigen, zorg dat je fouten hoort voordat je gebruikers ze melden, maak back-ups van de gegevens en bewijs dat je ze kunt herstellen, en houd de app snel genoeg op een telefoon. Niets daarvan vraagt om een herschrijving — het is een checklist die je doorloopt met dezelfde AI die het prototype heeft gebouwd.

Prototype versus productie: wat verandert er echt?

Een prototype heeft één zorgvuldige gebruiker: jijzelf. Je weet op welke knoppen je moet drukken, je typt verstandige invoer, en als er iets breekt, haal je je schouders op en vraag je de AI het te repareren. Productie heeft veel onzorgvuldige gebruikers, een paar nieuwsgierige en af en toe een vijandige. De code hoeft niet „enterprise” te worden; hij moet omgaan met de situaties die een prototype nooit tegenkomt.

De rest van deze gids loopt elke rij langs.

Stap 1: Bevries de scope en schrijf de belangrijkste flows op

Voordat je iets gaat verharden, bepaal je wat versie één is. Zet de drie tot zes flows op een rij die het meest tellen — bijvoorbeeld „aanmelden, een project maken, een teamlid uitnodigen, betalen”. Dit worden je testscript, je monitoringdoelen en de dingen die je controleert na elke wijziging.

Alles wat niet op de lijst staat, wordt geschrapt of duidelijk als bèta gelabeld. Het is veel makkelijker om vier flows betrouwbaar te maken dan veertien.

Stap 2: Test als een vreemde, en maak het daarna herhaalbaar

AI-bouwers zijn goed in code die op het ideale pad werkt. Productieproblemen zitten op de onbedoelde paden. Test elke belangrijke flow met:

• Verkeerde invoer: lege verplichte velden, een naam van 5.000 tekens, een e-mailadres zonder @, een negatief aantal, een datum in het verleden.
• Vernieuwen en de terugknop: herlaad halverwege het afrekenen; druk op terug na het versturen van een formulier. Wordt er iets dubbel aangemaakt?
• Twee tabbladen, twee gebruikers: log in met twee verschillende accounts en probeer elkaars pagina’s te openen door het ID in de URL te veranderen.
• Langzaam en klein: een schermformaat van een telefoon en een gedempte verbinding (browserontwikkeltools kunnen die simuleren).
• Lege staten: een gloednieuw account zonder gegevens. Prototypes worden vaak met voorbeeldgegevens gebouwd en zien er zonder die gegevens kapot uit.

Maak de controle daarna herhaalbaar. Houd minimaal een geschreven checklist bij en voer die uit vóór elke release. Nog beter is het om de AI geautomatiseerde tests te laten schrijven voor de flows die het meest tellen:

Voeg geautomatiseerde end-to-end-tests toe voor deze flows: aanmelden met e-mail, een project maken, een tweede gebruiker uitnodigen en afrekenen in de testmodus van Stripe. Voeg ook tests toe die bevestigen dat een gebruiker het project van een andere gebruiker niet kan bekijken of wijzigen door de URL aan te passen.

Tests die bewijzen dat een gebruiker iets niet kan doen, ontbreken in prototypes het vaakst.

Stap 3: Beveiligingsbasics die prototypes overslaan

De meeste beveiligingsproblemen in met AI gebouwde apps zijn niet exotisch. Er ontbreken controles. Loop deze lijst door, en zie de uitgebreidere beveiligingschecklist voor met AI gebouwde apps:

• Autorisatie op de server. Een knop verbergen is geen beveiliging. Elk verzoek dat gegevens leest of wijzigt, moet op de server controleren of de ingelogde gebruiker dat mag. Als je app een database met rijregels gebruikt, check dan of die aanstaan en zijn getest.
• Geheimen uit de browser. API-sleutels voor betalingen, e-mail of AI-providers horen in omgevingsvariabelen op de server, nooit in front-endcode. Als je niet zeker weet wat dat betekent, lees dan wat omgevingsvariabelen en geheimen zijn.
• Validatie op de server. De browser kan worden omzeild, dus herhaal elke controle die ertoe doet op de server.
• Inloggen goed geregeld. Gebruik een goed geteste authenticatiebibliotheek of -dienst in plaats van zelf wachtwoordopslag te bouwen. Onze gids over inloggen toevoegen aan je app behandelt de opties.
• Snelheidslimieten op inloggen, aanmelden, wachtwoord resetten en alles wat e-mail verstuurt of een betaalde API aanroept.
• Vriendelijke foutmeldingen. Gebruikers zien „er is iets misgegaan”; de details gaan naar je logs, niet naar het scherm.
• Vervang alles wat gelekt is. Als ooit een live sleutel in een chat, commit of screenshot is geplakt, vervang hem dan bij de provider.

Een prompt die veel tegelijk dekt:

Controleer deze app op productiebeveiliging. Kijk of elke API-route controleert dat de ingelogde gebruiker eigenaar is van het record dat wordt gelezen of gewijzigd, dat er geen geheime sleutels naar de browser worden gestuurd, dat invoer op de server wordt gevalideerd, en dat inloggen en wachtwoord resetten een snelheidslimiet hebben. Maak eerst een lijst van wat je vindt voordat je iets verandert.

Eerst om een lijst vragen laat je de problemen zien en de volgorde bepalen, in plaats van één enorme wijziging te krijgen.

Stap 4: Weet wanneer het misgaat — logging en monitoring

In het voorbeeld zie je fouten op het moment dat ze optreden. In productie moet de app het je laten weten. Drie lagen, van goedkoopst tot nuttigst:

1. Serverlogs. Zorg dat fouten worden gelogd met genoeg context om ze te reproduceren: welke route, welk gebruikers-ID (niet hun wachtwoord of kaartgegevens), welke vorm van invoer. Vraag de AI om gestructureerde logging toe te voegen als de app alleen naar de console schrijft.
2. Foutregistratie. Een dienst zoals Sentry of een vergelijkbare tool vangt uitzonderingen in front-end en back-end op, groepeert ze en stuurt je een e-mail. Voor een kleine app zijn de gratis versies van deze diensten vaak genoeg; controleer de actuele limieten op hun sites.
3. Uptimecontroles. Een externe dienst die elke paar minuten je startpagina en één belangrijke API-route laadt en je waarschuwt als die falen. Hiermee vang je problemen die de app helemaal laten stoppen met loggen.

Voeg nog een gewoonte toe: open na elke release de live app en voer je checklist voor de belangrijkste flows uit op de echte URL, niet alleen op het voorbeeld.

Stap 5: Back-ups en een weg terug

Twee verschillende dingen moeten worden beschermd, en ze worden makkelijk met elkaar verward.

• Code. Houd het project in versiebeheer zodat elke wijziging ongedaan kan worden gemaakt. Veel AI-bouwers bewaren checkpoints van je bestanden; synchroniseren met een Git-repository geeft je ook een kopie buiten de bouwer.
• Gegevens. Code terugdraaien draait de database niet terug. Een slechte migratie of een knop voor verwijderen met een bug kan rijen vernietigen die met geen enkel codecheckpoint terugkomen.

Voor gegevens stel je regelmatige back-ups in die ergens anders worden opgeslagen dan bij de hosting van de app — voor een Postgres-database is een ingeplande pg_dump naar aparte opslag de gebruikelijke aanpak, en veel beheerde databasehosts bieden automatische back-ups of herstel naar een moment in de tijd. Doe daarna de stap die de meeste mensen overslaan: zet een back-up terug in een tijdelijke database en controleer of de gegevens er zijn.

Vraag de AI ook om destructieve acties veiliger te maken: een bevestigingsstap voor verwijderen, en „zachte verwijdering” (rijen markeren als verwijderd in plaats van ze te wissen) voor alles wat gebruikers misschien terug willen.

Stap 6: Prestaties die standhouden op een telefoon

Prototypes voelen snel omdat jij de enige gebruiker bent en de gegevensset klein is. Vóór de lancering:

• Laad gegevens van echte omvang. Vraag de AI om een paar duizend rijen toe te voegen en te zien welke pagina’s traag worden. Lijsten hebben meestal paginering nodig, en de database heeft meestal indexen nodig op de kolommen waarop je filtert en sorteert.
• Verklein afbeeldingen. Te grote afbeeldingen zijn de meest voorkomende reden dat een pagina traag laadt. Vraag om geschaalde, gecomprimeerde afbeeldingen en lazy loading onder de vouw.
• Meet. Voer Lighthouse uit in de ontwikkeltools van Chrome op de live URL in mobiele modus. Googles Core Web Vitals zijn een verstandig doel: Largest Contentful Paint binnen 2,5 seconden, Interaction to Next Paint van 200 ms of minder, en Cumulative Layout Shift van 0,1 of minder.
• Let op „wektijd”-vertragingen. Hosting die in slaap valt als er niets gebeurt, bespaart geld, maar maakt het eerste bezoek na een rustige periode trager. Dat is voor een nieuwe app vaak een prima ruil; weet dat het gebeurt.

De projectenpagina is traag bij 5.000 rijen. Voeg paginering aan de serverkant toe (25 per pagina), voeg databaseindexen toe voor de kolommen waarop we filteren en sorteren, en toon een laadstatus terwijl de volgende pagina laadt.

Stap 7: Operationele basics

Een paar kleine dingen scheiden een hobby-app van een app die mensen vertrouwen:

• Een eigen domein met HTTPS. Zie hoe koppel je een eigen domein.
• Transactionele e-mail vanaf een geverifieerd domein voor bevestigingen bij aanmelden en wachtwoord resetten — behandeld in hoe stuur je e-mails vanuit je app.
• Privacybeleid en voorwaarden die beschrijven wat je daadwerkelijk verzamelt. Kopieer geen nalevingsclaims die je niet hebt waargemaakt.
• Een supportkanaal — zelfs een gemonitord e-mailadres.
• Gescheiden test- en live-sleutels voor betalingen en e-mail, en een duidelijke notitie welke omgeving welke gebruikt.

Stap 8: Een nette overdracht

Vroeg of laat werkt iemand anders aan de app: een freelancer, een nieuwe medeoprichter, of jijzelf over zes maanden. Maak dat makkelijk:

• Een README die uitlegt hoe je hem draait, welke omgevingsvariabelen hij nodig heeft (alleen namen, nooit waarden) en hoe je hem uitrolt.
• De checklist voor de belangrijkste flows en de geautomatiseerde tests.
• Een korte architectuurnotitie: front end, back end, database, diensten van derden, en waar elk wordt gehost.
• Een toegangslijst: wie beheerderstoegang heeft tot het domein, de hosting, de database, en de betaal- en e-mailaccounts. Zet die accounts op een zakelijk e-mailadres, niet op een persoonlijk.
• De code in Git, bij voorkeur gesynchroniseerd met een repository die van jou is. Als je later misschien van hosting wisselt, lees dan hoe exporteer je een met AI gebouwde app en host je hem zelf.

De AI kan het grootste deel hiervan voor je opstellen:

Schrijf een README voor dit project voor een ontwikkelaar die het nog nooit heeft gezien: wat de app doet, de techstack, hoe je hem lokaal draait, elke omgevingsvariabele die hij leest (alleen namen en doel), hoe het databaseschema is opgebouwd, en hoe je hem uitrolt.

Checklist voor productiegereedheid

• Belangrijkste flows opgeschreven en getest, inclusief „kan geen gegevens van iemand anders benaderen”
• Autorisatie en validatie aan de serverkant op elke route voor gegevens
• Geen geheime sleutels in front-endcode; gelekte sleutels vervangen
• Snelheidslimieten op authenticatie en alles wat geld kost
• Foutregistratie en uptimemeldingen die naar een inbox gaan die je leest
• Databaseback-ups buiten de hosting van de app, met één geslaagde testhersteloperatie
• Paginering en indexen gecontroleerd met realistische gegevens
• Eigen domein, geverifieerd verzenddomein, privacybeleid
• README en toegangslijst voor wie hierna komt

Dit doen met Mythex

Als je het prototype in Mythex hebt gebouwd, zijn de meeste stappen prompts in hetzelfde project. Typ /test en Mythex klikt door het live voorbeeld als een gebruiker en meldt kapotte flows — zie App Testing. Sleutels gaan in projectgeheimen en niet in de chat, elke geslaagde beurt van de agent slaat een checkpoint van je bestanden op waarnaar je kunt terugkeren, en publiceren geeft je een live URL met hosting, waarbij de database van hetzelfde creditsaldo wordt betaald (hostinglimieten legt uit hoe apps en databases in slaap vallen en weer wakker worden). Checkpoints dekken bestanden, niet databaserijen, dus plan je gegevensback-ups toch. Op Pro kun je een eigen domein koppelen en de code exporteren of synchroniseren met je eigen GitHub-repository voor een overdracht.

Veelgestelde vragen