De productiechecklist waar AI-gebouwde apps op stranden (7 dingen die stukgaan na de demo)

U hebt een app gebouwd met een AI-appbuilder, of hem op een paar avonden prompt voor prompt in elkaar gezet met vibe coding. Hij werkt. Maar kijk eens onder welke omstandigheden hij werkt: uw telefoon, uw wifi, uw account, data die u zelf hebt ingetypt, een build van een uur geleden. Een demo is een app die uitsluitend onder vriendelijke omstandigheden is getest.

Klaar voor productie betekent het omgekeerde: de app blijft werken zodra de vriendelijke omstandigheden wegvallen. Vreemden in plaats van u, een reviewer in plaats van een publiek, maanden in plaats van een middag.

Waarom die kloof bestaat, hebben we al eerder beschreven: ons artikel over de zeven muren tussen een prototype en de stores brengt de structurele afstand in kaart, en ons stuk over een app bouwen versus een app runnen benoemt het werk dat na de lancering begint. Die artikelen eindigen in vragen die u zichzelf zou moeten stellen. Dit artikel maakt van die vragen experimenten: zeven checks, elk met een concrete procedure en een slagingsvoorwaarde waarover niet te discussiëren valt, en allemaal deze week uitvoerbaar. Voelt een check saai aan, dan is dat precies de bedoeling. Productie is de plek waar de saaie bugs wonen.

1. Een vreemde kan een account aanmaken, weggaan en terugkomen

De demo logt nooit uit. U bouwde de app terwijl u al aangemeld was, op een toestel dat u herkent, dus de hele accountmachinerie bleef ongetest: de bevestigingsmail die in de spam belandt, de wachtwoordreset die nooit aankomt, de sessie die bij elke herstart sneuvelt, het account dat op uw telefoon bestaat en nergens anders. Accounts zijn het eerste wat een vreemde aanraakt en het laatste wat een demo test.

De check: maak op een toestel dat uw app nog nooit heeft gezien (de telefoon van een familielid volstaat, en voor een webapp een privévenster in de browser) een account aan met een e-mailadres dat van u is maar dat de app nog niet kent. Bevestig het. Log uit. Reset het wachtwoord. Log opnieuw in. Sluit de app en kom de volgende dag terug.

Geslaagd als: elke stap werkt zonder dat u een dashboard hoeft te openen, iets handmatig opnieuw hoeft te versturen of een omweg hoeft uit te leggen.

2. De app overleeft leeg, offline en dubbel getikt

Uw demo draait op data die u zelf hebt ingevoerd, over een goede verbinding, bediend door de enige persoon die weet waar hij niet moet klikken. Een echte gebruiker begint zonder dat alles: een gloednieuw account ziet nul content, de metro kapt de verbinding halverwege een actie af, en een ongeduldige duim tikt twee keer op de betaalknop. Dit zijn de saaie toestanden, en gegenereerde apps vangen ze doorgaans niet op, omdat niemand erom heeft geprompt. Apple komt er eerder aan toe dan uw gebruikers: in de ervaring van ons publicatieteam wordt een app tijdens de review geregeld offline geopend, en wat hij zonder netwerk laat zien, telt mee.

De check: installeer de app opnieuw, of open hem in een privévenster, en gebruik hem in vliegtuigmodus; verbreek de verbinding ook halverwege een actie. Loop daarna elk scherm door met een nieuw account dat nul data bevat. Tik vervolgens twee keer snel op elke knop die iets aanmaakt of afrekent. Houd de betaalkant in de testmodus van uw provider, of gebruik een goedkoop artikel dat u meteen terugbetaalt: u wilt weten of er twee bestellingen verschijnen, niet of er echt geld is afgeschreven.

Geslaagd als: geen lege schermen, geen eeuwig draaiende laadicoontjes, geen crash en geen dubbele bestelling.

3. De App Store en Google Play accepteren hem

Hier ontmoet de output van uw builder de buitenwereld. De stores willen gesigneerde native binaries, developeraccounts (99 USD per jaar bij Apple, eenmalig 25 USD bij Google), metadata voor de stores en privacyverklaringen die een paar jaar geleden nog niet bestonden: de sectie Data safety van Google Play is verplicht sinds juli 2022, de privacymanifesten van Apple sinds mei 2024. Veel prompt-to-app-tools genereren webapplicaties, want dat is wat een prompt in één stap kan deployen, dus deze muur komt doorgaans pas laat in zicht. Een webapp is een legitieme vorm (GoodBarber levert naast native ook een Progressive Web App), maar hij geeft de distributie van de stores op en, voor de meeste iOS-gebruikers, push. En dan komt de review: van de eerste inzendingen die ons publicatieteam in de twaalf maanden tot april 2026 behandelde, kwam ruwweg 42% afgewezen terug van Apple, en dat is het normale percentage voor een goed voorbereid team, geen straf voor beginners.

De check: drie vragen, beantwoord met namen in plaats van gissingen. Kan uw tool gesigneerde iOS- en Android-binaries opleveren? Hebt u developeraccounts bij Apple en Google? Kunt u vandaag benoemen welke data de app verzamelt, waar die wordt opgeslagen en welke externe diensten erbij kunnen?

Geslaagd als: drie keer ja, zwart op wit, voordat u een lanceerdatum vastlegt.

4. Een push die u vanavond inplant, staat morgen op het vergrendelscherm

Push is de reden waarom een app een website verslaat op retentie, en het is ook de feature die een demo het best kan veinzen: alles lijkt aangesloten tot de eerste vergrendelde telefoon. Bezorging is binair, en daarom is deze check een experiment van één nacht in plaats van een vraag. Sinds iOS 16.4 (maart 2023) bezorgt iOS webpush alleen aan webapps die de gebruiker bewust aan zijn beginscherm heeft toegevoegd; in de browser rinkelt er niets. Een AI-gebouwde webapp kan er op uw scherm dus identiek uitzien als een native app en toch verstommen zodra de telefoon op slot gaat. Vindt u in uw tool niet eens terug waar een pushmelding wordt ingepland, dan hebt u uw antwoord al: de check is mislukt.

De check: plan een pushmelding naar uw eigen telefoon in voor morgenochtend 7.00 uur, en vergrendel de telefoon vanavond.

Geslaagd als: het bericht op het vergrendelscherm staat wanneer u wakker wordt.

5. U kunt elke dienst noemen waarvan de app afhangt, en elke rekening

Een gegenereerde app is een geassembleerde app. Onder de demo zit een stack die de prompt voor u heeft gekozen: hier hosting, daar een database, een e-mailverzender, opslag voor afbeeldingen, statistieken, misschien een betaalprovider. Elk daarvan heeft een login, een gratis plan dat afloopt, sleutels die verlopen en een rekening die volgens zijn eigen curve meegroeit. De demo verbergt dit allemaal, want voor één gebruiker op één middag is alles gratis en is er nog niets stukgegaan. Productie stelt een hardere vraag: wanneer de app om 2 uur 's nachts plat ligt, welke van deze diensten controleert u dan eerst, en wie neemt er op?

De check: maak de inventaris, en begin waar iemand die niet programmeert werkelijk kán beginnen: doorzoek uw inbox op elke “Welcome to”- en “Verify your email”-mail die tijdens het bouwen binnenkwam, voeg elke login toe die u onderweg hebt aangemaakt, elke terugkerende afschrijving op uw kaartafschrift, en alles wat de integratie- en factuurpagina's van uw builder vermelden. Voor elke regel: wie het account beheert, wat het kost bij 1.000 gebruikers, en of het stilzwijgend wordt verlengd.

Geslaagd als: elke regel een eigenaar en een prijs heeft. Als het opstellen van de lijst u verraste, dan is die verrassing de conclusie.

Die inventaris komt later nog een tweede keer van pas. De diensten die erop staan, zijn namelijk ook precies wat u zou moeten vervangen als u ooit bij uw builder weggaat, en daar zit de echte lock-in: dat hebben we uit elkaar gehaald in uw app kan van u zijn zonder dat u ook weg kunt.

6. Eén wijziging gaat live zonder de rest mee te slepen

De eerste update is de zwaarste test voor een AI-gebouwde app, omdat er bij de lancering twee klokken beginnen te tikken. De eerste klok is de uwe: gebruikers vinden bugs, en ze via een prompt oplossen kan stilletjes delen herschrijven die al werkten, wat wij regeneration drift noemen (de regeneratie laat schermen verschuiven die u niet aanraakte). Op een gegenereerde codebase krijgt zelfs één labelwijziging zo een eigen lus: wijzig het label, regenereer, en ontdek vervolgens welke van de schermen die u niet aanraakte tóch veranderd zijn. De tweede klok is van Apple en Google: elk brengt jaarlijks een groot OS uit, Google verhoogt elk jaar de minimale Android-versie waarop een app moet mikken, en Apple verwijdert apps die drie jaar zonder update zitten en vrijwel geen downloads meer halen, na een vooraankondiging van 90 dagen. Een app die u niet veilig kunt wijzigen, is een app die u niet gepubliceerd kunt houden; voor de slow-motionversie hebben we uitgeschreven wat er stilletjes stukgaat wanneer een app stopt met updaten.

De check: wijzig één zichtbaar detail (een label, een prijs, een kleur) en breng het live: als store-update wanneer u al live bent, of door te regenereren en opnieuw te deployen wanneer u dat nog niet bent. Controleer daarna of drie dingen die eerst werkten, nog steeds werken.

Geslaagd als: de wijziging live staat, de drie opnieuw geteste flows nog werken, en de hele lus een middag kostte, geen week.

7. Iemand kan de app runnen zonder de builder opnieuw te openen

Over zes maanden is wat de app nodig heeft operationeel, niet generatief: het artikel van deze week publiceren, een prijs aanpassen, een klant antwoorden, de promotiepush versturen, de cijfers lezen. Als elk van die taken betekent dat u de tool heropent die de app genereerde en voorzichtig om alles heen prompt wat niet stuk mag, dan heeft de app een single point of failure: u, in de builder, voorgoed. Een app is beheerbaar wanneer zijn dagelijkse taken in een interface leven die daarvoor is gebouwd, of overgedragen kunnen worden aan iemand anders: een collega, of een AI-agent gekoppeld via een open protocol zoals MCP. Wie de run-helft van het werk doet, en waarmee, bepaalt meer van de toekomst van uw app dan welk scherm u ook genereerde.

De check: noteer de vijf taken die uw app elke week nodig zal hebben. Benoem voor elke taak wie hem doet en in welke tool.

Geslaagd als: geen van de vijf antwoorden luidt “ik, opnieuw aan het prompten in de builder, en dan maar hopen”.

Wees eerlijk bij het scoren. Zeven keer geslaagd: kondig de lancering aan. Eén of twee mislukkingen: dan weet u wat het werk van deze week is. Drie of meer: dan hebt u een gevalideerd idee, wat oprecht waardevol is, en het verdient een fundament dat gebouwd is voor het deel dat nu komt.

Dit is waarom wij deze checklist zonder aarzelen kunnen publiceren: op GoodBarber is het meeste ervan uw werk niet.

Checks 1 en 2 zijn kant-en-klaar. Accounts, sessies, offline gedrag en lege schermen worden geleverd als native componenten, gehard op de duizenden live apps die het platform host, in plaats van vers gegenereerd voor die van u. Check 3 is een service. GoodBarber compileert echte native binaries, Swift voor iOS en Kotlin voor Android, plus een Progressive Web App vanuit dezelfde configuratie. De privacyverklaringen waar Apple en Google om vragen delen hun bron van waarheid met de build zelf, namelijk de features die u hebt aangezet, zodat verklaring en binary niet uit elkaar kunnen groeien. En staat u liever niet alleen tegenover de review: het publicatieteam dat uw indiening kan overnemen, kreeg 91% van de eerste afwijzingen van Apple alsnog goedgekeurd (interne cijfers van het publicatieteam, twaalf maanden tot april 2026).

Check 4 is infrastructuur: de pushpipeline draait van begin tot eind op het platform en verwerkt enkele miljoenen meldingen per week. Check 5 krimpt tot één regel, omdat hosting, database, CMS, push, statistieken en betaalgateways in één abonnement leven, met 0% GoodBarber-commissie op e-commercetransacties. Die bundeling is de belangrijkste reden waarom de totale eigendomskosten uitkomen op ongeveer een tiende van maatwerkontwikkeling. En check 6 wordt stroomopwaarts opgevangen: verlegt Apple of Google een eis, dan patcht GoodBarber die één keer, en uw volgende update levert hem mee.

Check 7 is waar AI terugkeert, dit keer aan de goede kant van de demo. Elke GoodBarber-app kan door een AI-agent worden bediend via de MCP-server van het platform: vertel uw assistent wat u nodig hebt, en het artikel gaat eruit, de push wordt ingepland, de prijs verandert, en de cijfers van vorige week komen terug in gewone taal, vanuit Claude, ChatGPT, Cursor of elke andere MCP-compatibele client. Heel check 7 wordt zo een delegatiebeslissing. En agent-ready betekent dat de app door een agent bediend kán worden, niet dat hij zichzelf runt: de regels en de eindcontrole blijven bij u.

De scope van GoodBarber is contentapps en mobiele commerce: het bouwt geen games, en een marktplaats vol zware maatwerklogica verdient een ander antwoord, dat we u liever nu geven. Binnen die scope is deze checklist precies wat het platform gebouwd is om te dragen. Ergens wordt elke 4 seconden een GoodBarber-app gedownload, en de betalende klanten van het platform zijn verspreid over 152 landen. Dat is de optelsom van deze checks, jaar na jaar doorstaan.

Wat betekent “klaar voor productie” voor een mobiele app?

Een productieklare app overleeft de drie dingen die een demo nooit bevat: echte gebruikers, echte storereview en echte tijd. Concreet: vreemden kunnen zonder hulp een account aanmaken, de app vangt lege en offline toestanden op, de stores accepteren zijn gesigneerde binaries en privacyverklaringen, pushmeldingen worden bezorgd, elke dienst in zijn stack heeft een benoemde eigenaar, hij kan worden bijgewerkt zonder te breken wat al werkte, en zijn wekelijkse beheer hangt niet af van één persoon.

Is mijn AI-gebouwde app klaar voor productie?

Voer zeven checks uit: accountaanmaak en -herstel op een toestel dat de app nog nooit zag, lege en offline toestanden, indiening bij de stores met een gesigneerde native binary, pushbezorging op een vergrendelde telefoon, een geprijsde inventaris van elke dienst in de stack, één update die niets anders wijzigt dan wat de bedoeling was, en het week-in-week-uit beheer buiten de builder. Slaagt u voor alle zeven, dan kunt u de lancering aankondigen. De checks waarop u het waarschijnlijkst strandt, zijn de indiening bij de stores, push en de eerste update, omdat veel AI-appbuilders webapplicaties genereren in plaats van gesigneerde native binaries, en generatie geen storecompliance of onderhoud dekt.

Kan een AI-gebouwde app de App Store-review doorstaan?

Alleen als echte native app. Apple eist gesigneerde binaries, ingevulde privacyverklaringen en een app die meer is dan een herverpakte website (Guideline 4.2). Afwijzing is normaal, geen uitzondering: Apple wees ruwweg 42% af van de eerste inzendingen die het publicatieteam van GoodBarber in de twaalf maanden tot april 2026 behandelde, en 91% van die afwijzingen werd na aanpassingen alsnog geaccepteerd.

Wat gaat er als eerste stuk na de lancering van een AI-gebouwde app?

De saaie dingen, grofweg in deze volgorde: authenticatie (bevestigingsmails, wachtwoordresets, dode sessies), dan lege en offline toestanden, dan de pushbezorging, dan de eerste update, waarbij één bug oplossen via een prompt delen kan herschrijven die werkten. Het patroon erachter is telkens hetzelfde: een demo wordt getest onder vriendelijke omstandigheden, en productie haalt die één voor één weg.

Heb ik een ontwikkelaar nodig om een AI-gebouwde app draaiende te houden?

Als de app gegenereerde code op een geassembleerde stack is, moet iemand die code en die stack bezitten, en dat is ontwikkelaarswerk, of u het nu zelf kunt of niet. Op een beheerd platform als GoodBarber onderhoudt het engineeringteam van het platform de code, de hosting, de pushinfrastructuur en de storecompliance; u bedient de app vanuit een back-office, of draagt de dagelijkse taken over aan een AI-agent via de MCP-server. U houdt de rol van beheerder, niet die van engineer.

Volgende stap: niets van wat u bouwde is verloren moeite. De demo heeft de dure vraag beantwoord, namelijk of het idee een app verdient, en uw schermen zijn nu de specificatie. Start een gratis proefperiode bij GoodBarber, herbouw het idee tegen die specificatie, en voer dezelfde checklist uit op het resultaat: de eerste zes checks draagt het platform, en de zevende is één zin aan een agent.