Demo-klaar versus productieklaar: wanneer je met AI gebouwde app echt klaar is voor echte gebruikers
De meeste met AI gebouwde apps zien er in een demo geweldig uit en breken bij de derde echte gebruiker. Zo bepaal je aan welke kant je zit, en hoe je het gat dicht zonder ontwikkelaar.
Er is bij elke AI-appbouwer een moment waarop het ding dat je hebt gebouwd er echt begint uit te zien. De pagina laadt, de knoppen werken, het formulier accepteert invoer, en de data verschijnt waar het hoort. Je klikt rond en voelt je een oprichter. Dat is een goed gevoel. Het is ook waar veel mensen vastlopen — want het gat tussen “dit werkt als ik het demo” en “dit werkt als een vreemde het gebruikt” is groter dan het lijkt, en dat gat verschijnt niet in het previewvenster van de AI-appbouwer.
Deze post gaat over het bewust dichten van dat gat. Je hoeft geen engineer te worden om het te doen. Je moet weten waarop je moet testen, in welke volgorde, en wanneer je iets geen prototype meer noemt.
Wat “demo-klaar” eigenlijk betekent
Een demo-klare met AI gebouwde app doet het ding dat je wilde, op het pad waarop je hem testte, met data die lijkt op de data die je in prompts hebt geplakt. De login werkt. Het dashboard laadt. Het ding dat je aan je medeoprichter wilde laten zien staat op het scherm.
Demo-klaar is niet niets. Vier maanden geleden was wat je hebt gebouwd een freelance-opdracht en een tijdlijn van zes weken. Maar het is ook een versie van je app die getest is door jou, alleen, op het gelukkige pad. Echte gebruikers blijven niet op het gelukkige pad.
Ze plakken een e-mailadres met een dwalende spatie aan het eind. Ze gebruiken Safari op een iPad in liggende stand. Ze komen binnen op mobiele data en laten de pagina dertig seconden half geladen staan voordat ze op de knop tikken. Ze verwachten dat “terug” werkt, en ze verwachten dat vernieuwen niets verliest van wat ze hebben getypt.
De reden dat demo’s misleidend zijn, is niet dat de AI iets neps heeft gebouwd. Het is dat de persoon die de demo geeft weet waar de lijken begraven liggen. Je klikt instinctief op de knoppen die werken. Een echte gebruiker klikt op de knoppen waarvan je vergat dat ze bestonden.
De vijf dingen die als eerste breken
Bij de mensen die ik van demo naar lancering heb zien gaan met AI-appbouwers, neigen dezelfde vijf dingen de eerste te zijn die breken onder echte gebruikers. Ze bewust doorlopen is de snelste manier om richting productieklaar te bewegen.
1. De lege staat. Je dashboard ziet er geweldig uit met drie projecten erin, omdat je drie projecten gebruikte terwijl je aan het bouwen was. Een nieuwe gebruiker meldt zich aan, landt op een dashboard met nul van alles, en ziet een blanco grijze rechthoek. De fix is één prompt: “Wanneer de gebruiker nul projecten heeft, toon een vriendelijk bericht dat uitlegt wat hij vervolgens moet doen, en een knop om zijn eerste aan te maken.” Saai, tien seconden werk, maakt het verschil tussen “dit is kapot” en “dit is behulpzaam”.
2. De foutstaat. Probeer dit nu: zet je wifi uit en klik rond in je app. Typ een opzettelijk verkeerd wachtwoord. Dien een formulier in met het e-mailveld leeg. Als je app crasht, vastloopt of een rauwe fout toont als 500 Internal Server Error, heb je een foutstaatprobleem. De AI-bouwer kan dit oplossen, maar je moet vragen: “Wat gebeurt er als de API-aanroep mislukt? Als de gebruiker foute data invoert? Als ze offline zijn?” Dit zijn drie aparte prompts, en ze dekken de meeste manieren waarop echte gebruikers in de problemen komen.
3. De mobiele weergave. Ongeveer de helft van je eerste gebruikers — misschien meer, afhankelijk van wat je app is — opent hem op een telefoon. AI-bouwers handelen responsive design goed af voor standaardlay-outs en slecht voor aangepaste, vooral alles met een zijbalk, een vastgeplakte modal of een complex formulier. Open je app op je telefoon, met je andere duim, zoals een echte persoon hem gebruikt. Als iets buiten het scherm valt, iets te klein is om nauwkeurig op te tikken, of iets het toetsenbord bedekt als je probeert te typen, dan is dat een fix. Eén prompt, meestal: “Maak dat deze pagina er goed uitziet op een telefoonscherm, vooral het [ding dat kapot is] — laat de desktopversie ongewijzigd.”
4. Het ‘tweede gebruiker’-probleem. Hier is een sluwe. Veel met AI gebouwde apps gaan uit van één gebruiker. De data die je aanmaakt blijft in de app. Dan meldt een tweede gebruiker zich aan en ziet óf jouw data, óf geen data en raakt erg in de war. Dit is een authenticatie- en datascheidingsvraag, en het is de moeite waard om de AI te vragen uit te leggen hoe hij gebruikersdata opslaat voordat je lanceert. De juiste formulering: “Leg uit hoe gebruikersdata gescheiden wordt. Als twee mensen zich aanmelden, kan de een dan de data van de ander zien?” Het antwoord is de test.
5. De ‘ik bedacht me’-knop. Echte gebruikers maken voortdurend dingen ongedaan. Ze verwijderen het account dat ze net aanmaakten omdat ze de verkeerde e-mail typten. Ze zeggen twee minuten na het abonneren weer op. Ze willen een project bewerken dat ze gisteren maakten omdat de titel een typefout heeft. AI-appbouwers, aan hun lot overgelaten, bouwen het aanmaakpad en slaan het bewerk-of-verwijderpad over — omdat de demo ze alleen ooit vroeg om dingen aan te maken. Als je met dat gat lanceert, mailen je eerste drie gebruikers je binnen een uur, en de mail begint met het woord “Hoe”. Loop door je app en vraag, voor elk scherm: “Kan de gebruiker ongedaan maken wat hij net deed, of het later veranderen?” Overal waar het antwoord nee is, is dat een functie die je nodig hebt vóór de lancering.
Wat “productieklaar” niet betekent
Productieklaar voor een met AI gebouwde app is niet hetzelfde als productieklaar bij een bank. Je hebt geen 99,99% uptime nodig. Je hebt geen loadtest nodig. Je hebt geen runbook of een oproeprooster nodig. Je bent geen Stripe, je bent een klein ding dat echte mensen bedient.
Wat je wel nodig hebt, is een build die je niet voor schut zet voor een vreemde. Dat is haalbaar in een gefocuste middag of twee, zodra je weet waar je op moet letten. De vijf punten hierboven zijn het grootste deel ervan. De rest is de app leesbaar maken — duidelijke tekst op elke knop, voorspelbaar gedrag wanneer je klikt, geen pagina’s die doodlopen bij een terugpijl die niet werkt.
De grootste sprong van demo-klaar naar productieklaar zit niet in de code. Hij zit in je bereidheid om je eigen app te gebruiken zoals een vreemde dat zou doen. De truc die ik mensen aanraad: geef je telefoon aan een vriend in een koffiezaak en vraag ze het belangrijkste te doen dat je app doet, zonder het ze uit te leggen. Geef geen hints. Kijk naar hun duim. De eerste plek waar ze langer dan drie seconden pauzeren, is het belangrijkste dat je deze week kunt repareren. De tweede en derde plek zijn meestal snelle vervolgacties.
Een kleine lanceringschecklist
Voordat je naar je eerste tien echte gebruikers lanceert, loop deze checklist door. Niets ervan vereist het schrijven van code. Het is allemaal een prompt voor je AI-appbouwer of een handmatige doorklik.
- Ik heb me als gloednieuwe gebruiker aangemeld vanuit een privé-surfvenster, van begin tot eind, zonder shortcuts.
- Ik heb de app op mijn telefoon gebruikt.
- Ik heb geprobeerd de formulieren te breken — lege velden, rare invoer, heel lange invoer.
- Ik heb de AI-bouwer gevraagd hoe gebruikersdata gescheiden wordt, en het antwoord slaat ergens op.
- Ik heb een manier om gebruikers te bereiken als er iets misgaat (een e-mailveld, een feedbacklink, wat dan ook).
- Ik heb een manier om te weten wanneer er iets is misgegaan — de AI-bouwer biedt meestal basale foutlogging aan; zet het aan.
- De lege staat van elke pagina vertelt de gebruiker wat hij vervolgens moet doen.
- Elke actie die iets aanmaakt, heeft een manier om het ongedaan te maken, te bewerken of te verwijderen.
Als je deze lijst doorloopt en een paar punten ontbreken, dan zijn dat de prompts van morgen. Als je hem doorloopt en de meeste ontbreken, is de app nog niet klaar — en dat is een nuttig ding om te weten voordat je de link naar iemand stuurt.
De eerlijke middenweg
De meeste met AI gebouwde apps leven een tijdje in een middengebied. Ze werken, grotendeels. Ze hebben een paar ruwe randjes. Ze bedienen een kleine groep gebruikers goed en zouden bij schaal breken. Dat is een prima plek voor een startup of een interne tool om maandenlang te leven. De fout is om een demo-klare app te behandelen alsof hij al voorbij dat gebied is. De andere fout is om productieklaar te behandelen als een perfectionistische standaard die je nooit kunt bereiken.
De echte vraag is: zou ik me prettig voelen als een vriend dit gebruikte en terugrapporteerde? Zo ja, dan ben je productieklaar genoeg voor jouw fase. Als je liever snel iets zou repareren voordat ze je vertellen wat ze ervan vonden, schrijf dat ding dan op en repareer het eerst.
Je hoeft niet klaar te zijn voor tienduizend gebruikers. Je moet klaar zijn voor de volgende tien. Dat is een echte, eindige lijst met fixes, en je AI-appbouwer kan je helpen de meeste ervan in een middag te doen.
Als je een met AI gebouwde app naar echte gebruikers hebt gelanceerd, wat was het eerste dat brak dat je niet had voorspeld? Dat is meestal de interessantere vraag dan “is de mijne klaar” — want de verrassing is het echte signaal.