Een production readiness review (PRR) geeft die oprichter de blik die een operationeel team normaal meebrengt. Dit artikel beschrijft wat de review controleert, wanneer u hem uitvoert, wie welke rol vervult en hoe u tot een lanceringsbesluit komt. De bredere aanpak voor AI-code in productie staat in onze gids voor oprichters.
TL;DR
Een production readiness review (PRR) is een gestructureerde controle, vóór de lancering, of een product veilig en betrouwbaar kan draaien voor echte gebruikers, niet alleen of de code werkt. Bij een AI-gebouwd product voert iemand de review uit die onafhankelijk is van wie, of welke tool, de code heeft geschreven. De review eindigt in een lanceringsbesluit: go, go with conditions of not yet (doorgaan, doorgaan onder voorwaarden of nog niet).
- Een production readiness review van een AI-gebouwd product beslaat vijf gebieden: beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom.
- Een production readiness review start vóór de eerste betalende gebruikers, een enterprise-pilot of een overdracht aan een nieuwe developer, vroeg genoeg om elke blokkerende bevinding vóór de lanceringsdatum op te lossen.
- Een production readiness review vraagt drie rollen: een eigenaar die het PRR-document invult en bevindingen oplost, een onafhankelijke reviewer die het product niet heeft gebouwd, en een beslisser, meestal de oprichter of COO.
- Het lanceringsbesluit kent drie uitkomsten: nog niet zolang een blokkerende bevinding zoals blootgestelde productiesleutels openstaat, doorgaan onder voorwaarden als elke open bevinding een eigenaar en deadline heeft, en doorgaan als niets wezenlijks openstaat.
Wat is een production readiness review?
Een production readiness review is een gestructureerde controle of een product veilig kan worden beheerd voor echte gebruikers voordat het live gaat. In het Nederlands gaat het om productiegereedheid; sommige teams spreken van een production readiness assessment of een launch readiness review, maar de praktijk is dezelfde. “Productie” is de live-omgeving met echte klanten, echte gegevens en echt geld. De review stelt een andere vraag dan testen: niet “werkt de functie?”, maar “wat gebeurt er met gebruikers, gegevens en het bedrijf als er om twee uur ‘s nachts iets misgaat?”
De production readiness review komt uit Site Reliability Engineering (SRE): het vakgebied van de engineers die productiesystemen draaiende houden. Googles Site Reliability Engineering-boek (Beyer, Jones, Petoff en Murphy, O’Reilly, 2016) beschrijft de PRR als een proces dat de betrouwbaarheidsbehoeften van een dienst vaststelt op basis van de specifieke details ervan. De SRE-teams van Google voerden de review uit voordat zij een dienst overnamen van de developers die hem hadden gebouwd.
Productiegereedheid betekent in gewone taal: het product kan echte gebruikers, echte gegevens en storingen aan zonder dat de bouwer meekijkt. Een product is production ready als iemand anders dan de bouwer het kan beheren, kan zien wanneer het faalt en het kan herstellen.
De production readiness review wordt inmiddels ver buiten Google gebruikt. In het USENIX ;login:-artikel “Production Readiness Reviews: A Surprisingly Versatile Practice” (april 2025) adviseert Pedro Alves reviewers van buiten het team, noemt hij twee reviewers “the sweet spot” en zijn twee tot vier werksessies volgens hem gebruikelijk. Die drie voorwaarden — een onafhankelijke reviewer, een geschreven document en een klein aantal gerichte sessies — gelden net zo goed voor een AI-gebouwd product.
Waarom een AI-gebouwd product een andere review nodig heeft
Een klassieke production readiness review gaat uit van drie dingen: een operationeel team dat de dienst gaat beheren, gedocumenteerde architectuur en engineers die de code kennen. Een AI-gebouwd product heeft vaak geen van de drie. De oprichter is de beheerder, en een groot deel van de code is door een tool gegenereerd en nooit regel voor regel door een mens gelezen.
Dat verschil bepaalt wat de review moet vinden. Googles Simple PRR Model heeft zes fasen, van engagement tot continuous improvement; in de vijfde fase, onboarding, neemt een SRE-team de verantwoordelijkheid voor de dienst over. Na de review van een AI-gebouwd product neemt niemand het over. De production readiness review vervangt de blik van het ontbrekende operationele team en moet dus de onbekenden zichtbaar maken die de oprichter in een demo niet ziet.
| Klassieke PRR | PRR voor een AI-gebouwd product | |
|---|---|---|
| Wie heeft het gebouwd | Engineers in een productteam | Een oprichter, een freelancer of een klein team met een AI-appbouwer |
| Wie gaat het beheren | Een SRE- of operationeel team met een bereikbaarheidsdienst (rooster van wie op incidenten reageert) | De oprichter, meestal zonder bereikbaarheidsdienst |
| Wat is onbekend | Randgevallen, gedrag onder belasting, storingen tussen diensten | Welke codepaden er zijn, welke toegangsregels gelden en welke externe diensten gegevens bewaren |
| Documentatie | Architectuurnotities en runbooks (geschreven instructies voor bekende incidenten) bestaan | Weinig of niets; de code is het enige verslag |
| Typische blokkerende bevindingen | Ontbrekende meldingen, ongeteste failover, capaciteitsgrenzen | Open toegangsregels, sleutels in de frontend, betaal- of persoonsgegevensflows die niemand heeft getest |
| Wie beoordeelt | SRE-engineers van buiten het productteam | Een onafhankelijke engineer of reviewpartner die het product niet heeft gebouwd |
Wij raden aan de klassieke PRR-gebieden als kader te houden en de AI-specifieke onbekenden als eerste te bevragen, omdat blokkerende bevindingen meestal zitten in code die niemand heeft gelezen. Een product met gedocumenteerde architectuur en een ervaren developer kan met een lichtere versie toe; een product dat de oprichter zelf beheert en betalingen of persoonsgegevens verwerkt, heeft de volledige review nodig.
Wat een production readiness review omvat
Een production readiness review van een AI-gebouwd product beslaat vijf gebieden: beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom. Elk gebied hoort bij een klassiek PRR-onderwerp; het verschil zit in de volgorde van de vragen. De reviewer stelt eerst vast wat de code feitelijk doet, en pas daarna hoe goed.
Toegangsregels komen niet voor niets eerst. De OWASP Top 10:2025, de ranglijst van webapplicatierisico’s van het Open Worldwide Application Security Project, zet Broken Access Control op nummer één (A01:2025).
| Klassiek PRR-gebied | Gebied bij een AI-gebouwd product | Wat de review controleert | Voorbeeld van een blokkerende bevinding |
|---|---|---|---|
| Beveiliging | Beveiliging en data | Toegangsregels per rol, waar sleutels staan, waar persoonsgegevens worden opgeslagen | De geheime sleutel van een betaalprovider is leesbaar in de frontendcode |
| Architectuur en afhankelijkheden | Code en architectuur | Waar de bedrijfslogica draait, van welke diensten de app afhangt, ongebruikte codepaden | Prijzen of rechten worden alleen in de browser berekend, zodat een gebruiker ze kan aanpassen |
| Betrouwbaarheid | Betrouwbaarheid en kritieke flows | Wat er gebeurt als registratie, betaling of boeking halverwege mislukt; tests op die flows | Een mislukte betaling bevestigt toch de bestelling |
| Observability, deployment en rollback | Deployment en beheer | Observability (logs en meldingen die laten zien wat het systeem doet), releases, rollback (terug naar de laatste werkende versie), back-ups | Back-ups zijn nooit teruggezet, waardoor een mislukte release klantgegevens kan kosten |
| Eigendom | Onderhoudbaarheid en code-eigendom | Wie de repository-, hosting- en domeinaccounts beheert | De coderepository staat op het persoonlijke account van een voormalige freelancer |
Elk gebied heeft een langere lijst met controlepunten in de checklist productiegereedheid. Hoe diep een onafhankelijke audit per gebied gaat, leest u in ons artikel over de AI code audit.
Als uw app een AI-model aanroept
Dit deel van een production readiness review is geen beoordeling van de nauwkeurigheid van het AI-model; modelevaluatie is een apart vakgebied. Als een app gebruikersinvoer naar een modelleverancier stuurt, voegt de review vier vragen toe.
- Kan een gebruiker het model sturen? Het OWASP Gen AI Security Project spreekt van prompt injection wanneer gebruikersprompts het gedrag of de uitvoer van het taalmodel op onbedoelde wijze veranderen.
- Welke persoonsgegevens gaan naar de modelleverancier, en is er een verwerkersovereenkomst zoals artikel 28, lid 3 AVG vereist? De Autoriteit Persoonsgegevens legt uit wanneer een leverancier verwerker is.
- Wat doet de app als de leverancier een time-out geeft of verzoeken begrenst (rate limiting)?
- Is er een uitgavenlimiet voor modelgebruik? OWASP noemt “denial of wallet”-aanvallen onder LLM10:2025 Unbounded Consumption.
De controlepunten voor AI-modelfuncties staan in dezelfde checklist productiegereedheid.
Lanceert u binnenkort, zonder operationeel team om mee te kijken?
Een AI-built product review geeft u de onafhankelijke blik die een production readiness review nodig heeft: engineering en security samen beoordeeld, bevindingen in begrijpelijke taal en gerangschikt naar wat de lancering blokkeert en wat kan wachten.
Wanneer voert u een production readiness review uit?
Een production readiness review hoort plaats te vinden voordat het product echt risico gaat dragen voor anderen dan de oprichter. Vier momenten zijn aanleiding:
- vóór de eerste betalende gebruikers of een publieke lancering;
- vóór een enterprise-pilot of de beveiligingsvragenlijst van een klant;
- vóór de overdracht aan een bureau, een nieuwe developer of een bereikbaarheidsdienst;
- na een grote wijziging, zoals een nieuwe betaalflow, een nieuw soort persoonsgegevens of een herbouw.
De vuistregel voor de timing: begin vroeg genoeg om elke blokkerende bevinding vóór de lanceringsdatum op te lossen en opnieuw te laten controleren, en nooit in de lanceringsweek. De richtlijn uit USENIX ;login: van twee tot vier reviewsessies, plus één of twee vragensessies, is de minimale planning voordat het herstelwerk begint. Wij raden aan de review vóór een enterprise-pilot te starten, niet erna, omdat de beveiligingsvragenlijst van de pilotklant om hetzelfde bewijs vraagt dat de review oplevert.
Een production readiness review is evenredig aan het risico. Betaalflows en persoonsgegevens krijgen de volledige review; een interne tool voor vijf collega’s een lichtere. Voor producten die persoonsgegevens verwerken vraagt artikel 32, lid 1, onder d AVG om een procedure voor het regelmatig testen, beoordelen en evalueren van de doeltreffendheid van de beveiligingsmaatregelen. Een nieuwe review na elke grote wijziging hoort daarom in het releaseplan.
Wie voert de production readiness review uit?
Een production readiness review vraagt drie rollen, en in een klein bedrijf is de belangrijkste regel dat de reviewer het product niet zelf heeft gebouwd. Welke reviewmethode past, van een AI-zelfcontrole tot een penetratietest, vergelijken we in wie AI-gegenereerde code moet beoordelen. Binnen een PRR gaat het om de vraag wie wat doet.
Drie rollen: eigenaar, reviewer, beslisser
| Rol | Wie in een klein bedrijf | Verantwoordelijkheid |
|---|---|---|
| Eigenaar | Oprichter of lead developer | Vult het PRR-document in, beantwoordt de vragen van de reviewer, lost bevindingen op |
| Reviewer | Een onafhankelijke engineer of reviewpartner die het product niet heeft gebouwd | Leest code, configuratie en het PRR-document; rangschikt bevindingen naar impact op de lancering |
| Beslisser | Oprichter of COO | Beslist: doorgaan, doorgaan onder voorwaarden of nog niet, en is eigenaar van de voorwaarden |
De technische medeoprichter of freelancer die de app heeft gebouwd, is de juiste eigenaar en de verkeerde enige reviewer: een bouwer toetst tegen zijn eigen aannames, waardoor de gevallen waaraan hij nooit dacht ongetest blijven. In een klein bedrijf vult één onafhankelijke reviewpartner die engineering en security samen beoordeelt de plek van de reviewer.
Waar u op let bij een reviewer
Een reviewer voor de production readiness review van een AI-gebouwd product voldoet aan vijf criteria:
- Heeft productiesystemen beheerd. De reviewer heeft bereikbaarheidsdiensten gedraaid, een back-up teruggezet en een mislukte release teruggedraaid.
- Beoordeelt engineering en security samen. In een AI-gebouwd product is een open toegangsregel tegelijk een codebevinding en een beveiligingsbevinding.
- Staat los van het herstelwerk. De review wordt apart afgebakend en opgeleverd, zodat een vervolgopdracht de bevindingen niet kleurt.
- Legt bevindingen uit in begrijpelijke taal. Elke bevinding noemt de impact op gebruikers, gegevens of omzet.
- Zegt “nog niet” en onderbouwt dat. Vraag een kandidaat-reviewer om een voorbeeld van een “nog niet” dat hij heeft gerapporteerd, en wat er daarna veranderde.
Hoe de review verloopt: van PRR-document tot besluit
Een production readiness review verloopt in vier stappen, van een document van één pagina tot een besluitvergadering. Googles Simple PRR Model kent zes fasen omdat het eindigt met een SRE-team dat de dienst overneemt; een AI-gebouwd product heeft alleen de stappen nodig die naar een besluit leiden.
- De eigenaar vult een PRR-document van één pagina in vóór de eerste sessie.
- De reviewer leest code, configuratie en het document en stelt vragen in werksessies; twee tot vier sessies is de gebruikelijke bandbreedte volgens USENIX ;login:.
- De reviewer rangschikt de bevindingen naar impact op de lancering: blokkerend, voorwaarde of later.
- De beslisser houdt een besluitvergadering en legt de uitkomst vast, met de voorwaarden en per voorwaarde een eigenaar en een deadline.
Doorgaan, onder voorwaarden of nog niet: het lanceringsbesluit
Een production readiness review eindigt in een van drie uitkomsten, en het besluit ligt bij de oprichter; de review levert het bewijs. Een product met een open blokkerende bevinding is niet klaar, wat de lanceringsdatum ook zegt.
| Uitkomst | Wanneer | Wat er daarna gebeurt |
|---|---|---|
| Go (doorgaan) | Geen blokkerende bevindingen open; de overige bevindingen hebben weinig impact | Lanceren volgens plan; de overige bevindingen op de backlog zetten |
| Go with conditions (doorgaan onder voorwaarden) | Geen blokkerende bevindingen open; elke open bevinding heeft een eigenaar, een deadline en een besluit over beperkte lancering | Lanceren voor een beperkte groep gebruikers of achter een feature flag (een schakelaar die een functie alleen voor geselecteerde gebruikers aanzet); elke voorwaarde op de deadline controleren |
| Not yet (nog niet) | Minstens één blokkerende bevinding staat open | De blokkerende bevindingen oplossen, de opgeloste punten opnieuw laten beoordelen, een nieuwe besluitdatum vastleggen |
Drie soorten bevindingen zijn blokkerend: blootgestelde productiesleutels, aangetoonde onbevoegde toegang tot gevoelige gegevens, en storingen die een onaanvaardbaar privacy- of betaalrisico opleveren. Hoe die bevindingen zich in AI-gebouwde apps voordoen, leest u in beveiligingsrisico’s van vibe coding.
Bij persoonsgegevens ligt de inzet vast in de wet. Volgens artikel 33 AVG moet een datalek binnen 72 uur na ontdekking worden gemeld bij de toezichthouder, in Nederland de Autoriteit Persoonsgegevens.
“Doorgaan onder voorwaarden” werkt alleen als de voorwaarden op papier staan. Elke open bevinding krijgt een eigenaar, een deadline en een besluit over hoe ver de lancering beperkt blijft tot de bevinding is opgelost. Verloopt een deadline zonder oplossing, dan blijft de beperking staan; die vervalt niet vanzelf. Na de lancering laten twee van de vijf DORA-metrics voor softwarelevering, change fail rate en failed deployment recovery time, zien of de voorwaarden standhouden. Stijgt de change fail rate in de eerste weken, dan is dat een signaal om de lancering beperkt te houden.
Voorbeeld van een production readiness review: een AI-gebouwde boekingsapp
Illustratief voorbeeld — een fictief product, geen klantcase. Een oprichter heeft met een AI-appbouwer en één freelance developer een boekingsapp gebouwd voor fysiotherapiepraktijken in Nederland. Drie praktijken gebruiken de app in een pilot en over zes weken starten er twintig bij. De production readiness review leverde vijf bevindingen op.
| Gebied | Bevinding | Classificatie |
|---|---|---|
| Beveiliging en data | Patiënten zien afspraken van andere patiënten door het boekings-ID in de URL te wijzigen | Blokkerend |
| Beveiliging en data | De geheime Stripe-sleutel is leesbaar in de frontendcode | Blokkerend |
| Deployment en beheer | Geen melding als bevestigingsmails van afspraken mislukken | Voorwaarde |
| Betrouwbaarheid en kritieke flows | Geen tests op de annuleringsflow | Voorwaarde |
| Onderhoudbaarheid en code-eigendom | Geen README of installatie-instructies | Later |
Het eerste besluit was nog niet, omdat twee blokkerende bevindingen openstonden. De freelancer verplaatste de toegangscontrole naar de server, verving de Stripe-sleutel en zette die in een geheimenkluis aan de serverkant; de reviewer controleerde beide fixes opnieuw. Het tweede besluit was doorgaan onder voorwaarden: e-mailmeldingen vóór de start van een nieuwe praktijk, tests op de annuleringsflow binnen vier weken, en een lancering beperkt tot de drie pilotpraktijken plus vijf nieuwe tot beide voorwaarden zijn afgerond.
Een afspraak bij een fysiotherapeut laat zien dat een patiënt behandeld wordt. Dat maakt het een gezondheidsgegeven, een bijzondere categorie persoonsgegevens volgens artikel 9 AVG.
Hoe Sunbytes uw release vóór de lancering controleert
De twee blokkerende bevindingen in het voorbeeld van de boekingsapp — een gewijzigd boekings-ID dat de afspraken van een andere patiënt opent en een betaalsleutel die leesbaar is in de frontend — kwamen boven door de code te lezen, niet door de demo door te klikken. Code en configuratie met een frisse blik lezen is het deel van een production readiness review dat een oprichter niet alleen kan doen, en dat deel neemt Sunbytes op zich.
Met de AI-built product review neemt Sunbytes de rol van reviewer in uw PRR in. Een reviewer die het product niet heeft gebouwd, leest code en configuratie op beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom. Een open toegangsregel wordt vastgelegd als codebevinding én als beveiligingsbevinding, en elke bevinding krijgt een van drie labels: blokkerend, voorwaarde of later. U ontvangt een geprioriteerd actieplan in begrijpelijke taal, zodat het besluit — doorgaan, doorgaan onder voorwaarden of nog niet — bij u blijft en op bewijs rust. De review wordt los van herstelwerk afgebakend, zodat een vervolgopdracht de bevindingen niet kleurt.
Twee andere Sunbytes-teams komen alleen in beeld als de bevindingen daarom vragen. Vraagt een enterprise-pilotklant om beveiligingsbewijs dat verder gaat dan de review, zoals toegangsbeheer, sleutelbeheer of AVG-registraties, dan zorgt Cybersecurity-oplossingen voor die maatregelen. Vraagt het oplossen van de blokkerende bevindingen vóór de lanceringsdatum meer engineers dan u hebt, dan neemt een dedicated software development team het herstelwerk op zich als aparte opdracht, zodat de reviewer nooit de fixes van eigen collega’s beoordeelt.
Toegang tot uw repository en productieconfiguratie valt onder het ISO/IEC 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes, met governance vanuit het hoofdkantoor in Nederland en engineering vanuit de delivery hub in Vietnam. Bij een product met patiëntafspraken of betaalgegevens weegt die toegangscontrole even zwaar als de bevindingen: de reviewer werkt in precies de systemen die de review moet beschermen, met 15+ jaar ervaring in softwarelevering erachter.
Staat uw lanceringsdatum al vast? Plan dan een AI-built product review, vroeg genoeg om elke blokkerende bevinding vóór die datum op te lossen en opnieuw te laten controleren.
Een production readiness review is ontworpen voor bedrijven met een eigen reliability-team. De meeste AI-gebouwde producten gaan live zonder zo’n team, en juist daarom is de review voor hen belangrijker, niet minder belangrijk. Wie een product bouwt met een AI-appbouwer zoals Lovable, Bolt, Replit of Cursor, wordt meestal ook de beheerder: degene die het bericht krijgt als afspraken niet meer binnenkomen of een klant de verkeerde gegevens ziet.
Een production readiness review (PRR) geeft die oprichter de blik die een operationeel team normaal meebrengt. Dit artikel beschrijft wat de review controleert, wanneer u hem uitvoert, wie welke rol vervult en hoe u tot een lanceringsbesluit komt. De bredere aanpak voor AI-code in productie staat in onze gids voor oprichters.
TL;DR
Een production readiness review (PRR) is een gestructureerde controle, vóór de lancering, of een product veilig en betrouwbaar kan draaien voor echte gebruikers, niet alleen of de code werkt. Bij een AI-gebouwd product voert iemand de review uit die onafhankelijk is van wie, of welke tool, de code heeft geschreven. De review eindigt in een lanceringsbesluit: go, go with conditions of not yet (doorgaan, doorgaan onder voorwaarden of nog niet).
- Een production readiness review van een AI-gebouwd product beslaat vijf gebieden: beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom.
- Een production readiness review start vóór de eerste betalende gebruikers, een enterprise-pilot of een overdracht aan een nieuwe developer, vroeg genoeg om elke blokkerende bevinding vóór de lanceringsdatum op te lossen.
- Een production readiness review vraagt drie rollen: een eigenaar die het PRR-document invult en bevindingen oplost, een onafhankelijke reviewer die het product niet heeft gebouwd, en een beslisser, meestal de oprichter of COO.
- Het lanceringsbesluit kent drie uitkomsten: nog niet zolang een blokkerende bevinding zoals blootgestelde productiesleutels openstaat, doorgaan onder voorwaarden als elke open bevinding een eigenaar en deadline heeft, en doorgaan als niets wezenlijks openstaat.
Wat is een production readiness review?
Een production readiness review is een gestructureerde controle of een product veilig kan worden beheerd voor echte gebruikers voordat het live gaat. In het Nederlands gaat het om productiegereedheid; sommige teams spreken van een production readiness assessment of een launch readiness review, maar de praktijk is dezelfde. “Productie” is de live-omgeving met echte klanten, echte gegevens en echt geld. De review stelt een andere vraag dan testen: niet “werkt de functie?”, maar “wat gebeurt er met gebruikers, gegevens en het bedrijf als er om twee uur ‘s nachts iets misgaat?”
De production readiness review komt uit Site Reliability Engineering (SRE): het vakgebied van de engineers die productiesystemen draaiende houden. Googles Site Reliability Engineering-boek (Beyer, Jones, Petoff en Murphy, O’Reilly, 2016) beschrijft de PRR als een proces dat de betrouwbaarheidsbehoeften van een dienst vaststelt op basis van de specifieke details ervan. De SRE-teams van Google voerden de review uit voordat zij een dienst overnamen van de developers die hem hadden gebouwd.
Productiegereedheid betekent in gewone taal: het product kan echte gebruikers, echte gegevens en storingen aan zonder dat de bouwer meekijkt. Een product is production ready als iemand anders dan de bouwer het kan beheren, kan zien wanneer het faalt en het kan herstellen.
De production readiness review wordt inmiddels ver buiten Google gebruikt. In het USENIX ;login:-artikel “Production Readiness Reviews: A Surprisingly Versatile Practice” (april 2025) adviseert Pedro Alves reviewers van buiten het team, noemt hij twee reviewers “the sweet spot” en zijn twee tot vier werksessies volgens hem gebruikelijk. Die drie voorwaarden — een onafhankelijke reviewer, een geschreven document en een klein aantal gerichte sessies — gelden net zo goed voor een AI-gebouwd product.
Waarom een AI-gebouwd product een andere review nodig heeft
Een klassieke production readiness review gaat uit van drie dingen: een operationeel team dat de dienst gaat beheren, gedocumenteerde architectuur en engineers die de code kennen. Een AI-gebouwd product heeft vaak geen van de drie. De oprichter is de beheerder, en een groot deel van de code is door een tool gegenereerd en nooit regel voor regel door een mens gelezen.
Dat verschil bepaalt wat de review moet vinden. Googles Simple PRR Model heeft zes fasen, van engagement tot continuous improvement; in de vijfde fase, onboarding, neemt een SRE-team de verantwoordelijkheid voor de dienst over. Na de review van een AI-gebouwd product neemt niemand het over. De production readiness review vervangt de blik van het ontbrekende operationele team en moet dus de onbekenden zichtbaar maken die de oprichter in een demo niet ziet.
| Klassieke PRR | PRR voor een AI-gebouwd product | |
|---|---|---|
| Wie heeft het gebouwd | Engineers in een productteam | Een oprichter, een freelancer of een klein team met een AI-appbouwer |
| Wie gaat het beheren | Een SRE- of operationeel team met een bereikbaarheidsdienst (rooster van wie op incidenten reageert) | De oprichter, meestal zonder bereikbaarheidsdienst |
| Wat is onbekend | Randgevallen, gedrag onder belasting, storingen tussen diensten | Welke codepaden er zijn, welke toegangsregels gelden en welke externe diensten gegevens bewaren |
| Documentatie | Architectuurnotities en runbooks (geschreven instructies voor bekende incidenten) bestaan | Weinig of niets; de code is het enige verslag |
| Typische blokkerende bevindingen | Ontbrekende meldingen, ongeteste failover, capaciteitsgrenzen | Open toegangsregels, sleutels in de frontend, betaal- of persoonsgegevensflows die niemand heeft getest |
| Wie beoordeelt | SRE-engineers van buiten het productteam | Een onafhankelijke engineer of reviewpartner die het product niet heeft gebouwd |
Wij raden aan de klassieke PRR-gebieden als kader te houden en de AI-specifieke onbekenden als eerste te bevragen, omdat blokkerende bevindingen meestal zitten in code die niemand heeft gelezen. Een product met gedocumenteerde architectuur en een ervaren developer kan met een lichtere versie toe; een product dat de oprichter zelf beheert en betalingen of persoonsgegevens verwerkt, heeft de volledige review nodig.
Wat een production readiness review omvat
Een production readiness review van een AI-gebouwd product beslaat vijf gebieden: beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom. Elk gebied hoort bij een klassiek PRR-onderwerp; het verschil zit in de volgorde van de vragen. De reviewer stelt eerst vast wat de code feitelijk doet, en pas daarna hoe goed.
Toegangsregels komen niet voor niets eerst. De OWASP Top 10:2025, de ranglijst van webapplicatierisico’s van het Open Worldwide Application Security Project, zet Broken Access Control op nummer één (A01:2025).
| Klassiek PRR-gebied | Gebied bij een AI-gebouwd product | Wat de review controleert | Voorbeeld van een blokkerende bevinding |
|---|---|---|---|
| Beveiliging | Beveiliging en data | Toegangsregels per rol, waar sleutels staan, waar persoonsgegevens worden opgeslagen | De geheime sleutel van een betaalprovider is leesbaar in de frontendcode |
| Architectuur en afhankelijkheden | Code en architectuur | Waar de bedrijfslogica draait, van welke diensten de app afhangt, ongebruikte codepaden | Prijzen of rechten worden alleen in de browser berekend, zodat een gebruiker ze kan aanpassen |
| Betrouwbaarheid | Betrouwbaarheid en kritieke flows | Wat er gebeurt als registratie, betaling of boeking halverwege mislukt; tests op die flows | Een mislukte betaling bevestigt toch de bestelling |
| Observability, deployment en rollback | Deployment en beheer | Observability (logs en meldingen die laten zien wat het systeem doet), releases, rollback (terug naar de laatste werkende versie), back-ups | Back-ups zijn nooit teruggezet, waardoor een mislukte release klantgegevens kan kosten |
| Eigendom | Onderhoudbaarheid en code-eigendom | Wie de repository-, hosting- en domeinaccounts beheert | De coderepository staat op het persoonlijke account van een voormalige freelancer |
Elk gebied heeft een langere lijst met controlepunten in de checklist productiegereedheid. Hoe diep een onafhankelijke audit per gebied gaat, leest u in ons artikel over de AI code audit.
Als uw app een AI-model aanroept
Dit deel van een production readiness review is geen beoordeling van de nauwkeurigheid van het AI-model; modelevaluatie is een apart vakgebied. Als een app gebruikersinvoer naar een modelleverancier stuurt, voegt de review vier vragen toe.
- Kan een gebruiker het model sturen? Het OWASP Gen AI Security Project spreekt van prompt injection wanneer gebruikersprompts het gedrag of de uitvoer van het taalmodel op onbedoelde wijze veranderen.
- Welke persoonsgegevens gaan naar de modelleverancier, en is er een verwerkersovereenkomst zoals artikel 28, lid 3 AVG vereist? De Autoriteit Persoonsgegevens legt uit wanneer een leverancier verwerker is.
- Wat doet de app als de leverancier een time-out geeft of verzoeken begrenst (rate limiting)?
- Is er een uitgavenlimiet voor modelgebruik? OWASP noemt “denial of wallet”-aanvallen onder LLM10:2025 Unbounded Consumption.
De controlepunten voor AI-modelfuncties staan in dezelfde checklist productiegereedheid.
Lanceert u binnenkort, zonder operationeel team om mee te kijken?
Een AI-built product review geeft u de onafhankelijke blik die een production readiness review nodig heeft: engineering en security samen beoordeeld, bevindingen in begrijpelijke taal en gerangschikt naar wat de lancering blokkeert en wat kan wachten.
Wanneer voert u een production readiness review uit?
Een production readiness review hoort plaats te vinden voordat het product echt risico gaat dragen voor anderen dan de oprichter. Vier momenten zijn aanleiding:
- vóór de eerste betalende gebruikers of een publieke lancering;
- vóór een enterprise-pilot of de beveiligingsvragenlijst van een klant;
- vóór de overdracht aan een bureau, een nieuwe developer of een bereikbaarheidsdienst;
- na een grote wijziging, zoals een nieuwe betaalflow, een nieuw soort persoonsgegevens of een herbouw.
De vuistregel voor de timing: begin vroeg genoeg om elke blokkerende bevinding vóór de lanceringsdatum op te lossen en opnieuw te laten controleren, en nooit in de lanceringsweek. De richtlijn uit USENIX ;login: van twee tot vier reviewsessies, plus één of twee vragensessies, is de minimale planning voordat het herstelwerk begint. Wij raden aan de review vóór een enterprise-pilot te starten, niet erna, omdat de beveiligingsvragenlijst van de pilotklant om hetzelfde bewijs vraagt dat de review oplevert.
Een production readiness review is evenredig aan het risico. Betaalflows en persoonsgegevens krijgen de volledige review; een interne tool voor vijf collega’s een lichtere. Voor producten die persoonsgegevens verwerken vraagt artikel 32, lid 1, onder d AVG om een procedure voor het regelmatig testen, beoordelen en evalueren van de doeltreffendheid van de beveiligingsmaatregelen. Een nieuwe review na elke grote wijziging hoort daarom in het releaseplan.
Wie voert de production readiness review uit?
Een production readiness review vraagt drie rollen, en in een klein bedrijf is de belangrijkste regel dat de reviewer het product niet zelf heeft gebouwd. Welke reviewmethode past, van een AI-zelfcontrole tot een penetratietest, vergelijken we in wie AI-gegenereerde code moet beoordelen. Binnen een PRR gaat het om de vraag wie wat doet.
Drie rollen: eigenaar, reviewer, beslisser
| Rol | Wie in een klein bedrijf | Verantwoordelijkheid |
|---|---|---|
| Eigenaar | Oprichter of lead developer | Vult het PRR-document in, beantwoordt de vragen van de reviewer, lost bevindingen op |
| Reviewer | Een onafhankelijke engineer of reviewpartner die het product niet heeft gebouwd | Leest code, configuratie en het PRR-document; rangschikt bevindingen naar impact op de lancering |
| Beslisser | Oprichter of COO | Beslist: doorgaan, doorgaan onder voorwaarden of nog niet, en is eigenaar van de voorwaarden |
De technische medeoprichter of freelancer die de app heeft gebouwd, is de juiste eigenaar en de verkeerde enige reviewer: een bouwer toetst tegen zijn eigen aannames, waardoor de gevallen waaraan hij nooit dacht ongetest blijven. In een klein bedrijf vult één onafhankelijke reviewpartner die engineering en security samen beoordeelt de plek van de reviewer.
Waar u op let bij een reviewer
Een reviewer voor de production readiness review van een AI-gebouwd product voldoet aan vijf criteria:
- Heeft productiesystemen beheerd. De reviewer heeft bereikbaarheidsdiensten gedraaid, een back-up teruggezet en een mislukte release teruggedraaid.
- Beoordeelt engineering en security samen. In een AI-gebouwd product is een open toegangsregel tegelijk een codebevinding en een beveiligingsbevinding.
- Staat los van het herstelwerk. De review wordt apart afgebakend en opgeleverd, zodat een vervolgopdracht de bevindingen niet kleurt.
- Legt bevindingen uit in begrijpelijke taal. Elke bevinding noemt de impact op gebruikers, gegevens of omzet.
- Zegt “nog niet” en onderbouwt dat. Vraag een kandidaat-reviewer om een voorbeeld van een “nog niet” dat hij heeft gerapporteerd, en wat er daarna veranderde.
Hoe de review verloopt: van PRR-document tot besluit
Een production readiness review verloopt in vier stappen, van een document van één pagina tot een besluitvergadering. Googles Simple PRR Model kent zes fasen omdat het eindigt met een SRE-team dat de dienst overneemt; een AI-gebouwd product heeft alleen de stappen nodig die naar een besluit leiden.
- De eigenaar vult een PRR-document van één pagina in vóór de eerste sessie.
- De reviewer leest code, configuratie en het document en stelt vragen in werksessies; twee tot vier sessies is de gebruikelijke bandbreedte volgens USENIX ;login:.
- De reviewer rangschikt de bevindingen naar impact op de lancering: blokkerend, voorwaarde of later.
- De beslisser houdt een besluitvergadering en legt de uitkomst vast, met de voorwaarden en per voorwaarde een eigenaar en een deadline.
Doorgaan, onder voorwaarden of nog niet: het lanceringsbesluit
Een production readiness review eindigt in een van drie uitkomsten, en het besluit ligt bij de oprichter; de review levert het bewijs. Een product met een open blokkerende bevinding is niet klaar, wat de lanceringsdatum ook zegt.
| Uitkomst | Wanneer | Wat er daarna gebeurt |
|---|---|---|
| Go (doorgaan) | Geen blokkerende bevindingen open; de overige bevindingen hebben weinig impact | Lanceren volgens plan; de overige bevindingen op de backlog zetten |
| Go with conditions (doorgaan onder voorwaarden) | Geen blokkerende bevindingen open; elke open bevinding heeft een eigenaar, een deadline en een besluit over beperkte lancering | Lanceren voor een beperkte groep gebruikers of achter een feature flag (een schakelaar die een functie alleen voor geselecteerde gebruikers aanzet); elke voorwaarde op de deadline controleren |
| Not yet (nog niet) | Minstens één blokkerende bevinding staat open | De blokkerende bevindingen oplossen, de opgeloste punten opnieuw laten beoordelen, een nieuwe besluitdatum vastleggen |
Drie soorten bevindingen zijn blokkerend: blootgestelde productiesleutels, aangetoonde onbevoegde toegang tot gevoelige gegevens, en storingen die een onaanvaardbaar privacy- of betaalrisico opleveren. Hoe die bevindingen zich in AI-gebouwde apps voordoen, leest u in beveiligingsrisico’s van vibe coding.
Bij persoonsgegevens ligt de inzet vast in de wet. Volgens artikel 33 AVG moet een datalek binnen 72 uur na ontdekking worden gemeld bij de toezichthouder, in Nederland de Autoriteit Persoonsgegevens.
“Doorgaan onder voorwaarden” werkt alleen als de voorwaarden op papier staan. Elke open bevinding krijgt een eigenaar, een deadline en een besluit over hoe ver de lancering beperkt blijft tot de bevinding is opgelost. Verloopt een deadline zonder oplossing, dan blijft de beperking staan; die vervalt niet vanzelf. Na de lancering laten twee van de vijf DORA-metrics voor softwarelevering, change fail rate en failed deployment recovery time, zien of de voorwaarden standhouden. Stijgt de change fail rate in de eerste weken, dan is dat een signaal om de lancering beperkt te houden.
Voorbeeld van een production readiness review: een AI-gebouwde boekingsapp
Illustratief voorbeeld — een fictief product, geen klantcase. Een oprichter heeft met een AI-appbouwer en één freelance developer een boekingsapp gebouwd voor fysiotherapiepraktijken in Nederland. Drie praktijken gebruiken de app in een pilot en over zes weken starten er twintig bij. De production readiness review leverde vijf bevindingen op.
| Gebied | Bevinding | Classificatie |
|---|---|---|
| Beveiliging en data | Patiënten zien afspraken van andere patiënten door het boekings-ID in de URL te wijzigen | Blokkerend |
| Beveiliging en data | De geheime Stripe-sleutel is leesbaar in de frontendcode | Blokkerend |
| Deployment en beheer | Geen melding als bevestigingsmails van afspraken mislukken | Voorwaarde |
| Betrouwbaarheid en kritieke flows | Geen tests op de annuleringsflow | Voorwaarde |
| Onderhoudbaarheid en code-eigendom | Geen README of installatie-instructies | Later |
Het eerste besluit was nog niet, omdat twee blokkerende bevindingen openstonden. De freelancer verplaatste de toegangscontrole naar de server, verving de Stripe-sleutel en zette die in een geheimenkluis aan de serverkant; de reviewer controleerde beide fixes opnieuw. Het tweede besluit was doorgaan onder voorwaarden: e-mailmeldingen vóór de start van een nieuwe praktijk, tests op de annuleringsflow binnen vier weken, en een lancering beperkt tot de drie pilotpraktijken plus vijf nieuwe tot beide voorwaarden zijn afgerond.
Een afspraak bij een fysiotherapeut laat zien dat een patiënt behandeld wordt. Dat maakt het een gezondheidsgegeven, een bijzondere categorie persoonsgegevens volgens artikel 9 AVG.
Hoe Sunbytes uw release vóór de lancering controleert
De twee blokkerende bevindingen in het voorbeeld van de boekingsapp — een gewijzigd boekings-ID dat de afspraken van een andere patiënt opent en een betaalsleutel die leesbaar is in de frontend — kwamen boven door de code te lezen, niet door de demo door te klikken. Code en configuratie met een frisse blik lezen is het deel van een production readiness review dat een oprichter niet alleen kan doen, en dat deel neemt Sunbytes op zich.
Met de AI-built product review neemt Sunbytes de rol van reviewer in uw PRR in. Een reviewer die het product niet heeft gebouwd, leest code en configuratie op beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en code-eigendom. Een open toegangsregel wordt vastgelegd als codebevinding én als beveiligingsbevinding, en elke bevinding krijgt een van drie labels: blokkerend, voorwaarde of later. U ontvangt een geprioriteerd actieplan in begrijpelijke taal, zodat het besluit — doorgaan, doorgaan onder voorwaarden of nog niet — bij u blijft en op bewijs rust. De review wordt los van herstelwerk afgebakend, zodat een vervolgopdracht de bevindingen niet kleurt.
Twee andere Sunbytes-teams komen alleen in beeld als de bevindingen daarom vragen. Vraagt een enterprise-pilotklant om beveiligingsbewijs dat verder gaat dan de review, zoals toegangsbeheer, sleutelbeheer of AVG-registraties, dan zorgt Cybersecurity-oplossingen voor die maatregelen. Vraagt het oplossen van de blokkerende bevindingen vóór de lanceringsdatum meer engineers dan u hebt, dan neemt een dedicated software development team het herstelwerk op zich als aparte opdracht, zodat de reviewer nooit de fixes van eigen collega’s beoordeelt.
Toegang tot uw repository en productieconfiguratie valt onder het ISO/IEC 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes, met governance vanuit het hoofdkantoor in Nederland en engineering vanuit de delivery hub in Vietnam. Bij een product met patiëntafspraken of betaalgegevens weegt die toegangscontrole even zwaar als de bevindingen: de reviewer werkt in precies de systemen die de review moet beschermen, met 15+ jaar ervaring in softwarelevering erachter.
Staat uw lanceringsdatum al vast? Plan dan een AI-built product review, vroeg genoeg om elke blokkerende bevinding vóór die datum op te lossen en opnieuw te laten controleren.
