Programma van eisen app: template van één pagina

Programma van eisen voor een mobiele app: het korte antwoord

Een goed programma van eisen voor een mobiele app past op één pagina als je je eigen app bouwt. Het beantwoordt tien vragen: voor wie, welk probleem, welke hoofdfunctie, hoe de app geld verdient, wat er gebeurt zonder account, welke gegevens bewaard moeten blijven, op welk platform, wat buiten de eerste versie valt, hoe je weet dat het werkt, en met welke beperkingen. De template om te kopiëren staat verderop. Je kunt ook de template en de validatietabel downloaden (.md), zonder je aan te melden.

De templates van 40 pagina's die je online vindt, zijn voor iets anders geschreven: een klant die een app bestelt bij een bureau en een contractueel document nodig heeft. Jij bent tegelijk degene die beslist en degene die bouwt, vaak met hulp van AI. Jouw programma van eisen dient twee doelen: beslissingen nemen voordat je gaat coderen, en Claude, ChatGPT of Cursor duidelijke context geven zodat ze de juiste app bouwen.

Ik publiceer mijn eigen iOS-apps. Solys, een wekker met minigames, en TradaZen, een tradingsimulator, staan in de App Store. Nolera en Clic werden door Apple afgewezen en daarna gecorrigeerd. Dit is de methode die ik voor elk van die apps gebruik, en die ik je hier aanraad.

Waarom één pagina genoeg is om je eigen app af te bakenen

Een lang document geeft het gevoel dat je vooruitgang hebt geboekt. In de praktijk schrijf je het één keer, lees je het zelden terug, en wijkt het project er in de eerste weken al van af. Eén pagina lees je daarentegen in twee minuten terug voor elke werksessie.

De beperkte ruimte heeft ook een nuttig effect: je moet kiezen. Is een antwoord langer dan twee zinnen, dan is de beslissing vaak nog niet genomen. Dat ontdek je beter op papier dan drie weken later in je code.

En één pagina is precies de goede omvang voor AI. Je kunt hem in zijn geheel in een gesprek plakken, of in het contextbestand van je project zetten. Een kort document is makkelijker na te lezen en bevat minder tegenstrijdige instructies. Het garandeert niet dat de AI ze opvolgt: controleer de voorstellen tegen dit kader.

Wat moet er in een programma van eisen voor een mobiele app staan?

Beantwoord elk van deze vragen in een of twee zinnen.

1. Wie gebruikt de app, en in welke situatie? Niet "18- tot 35-jarigen". Liever één concreet persoon, op een concreet moment van de dag.
2. Welk probleem lost de app op, in één zin? Heb je "en ook" nodig, dan beschrijf je twee apps.
3. Wat is DE hoofdfunctie van de eerste versie? Eén. De rest wacht op de cijfers. De pagina MVP van een iOS-app legt uit hoe je kiest.
4. Hoe verdient de app geld? Abonnement, eenmalige aankoop of gratis. Dat antwoord verandert de app vanaf het eerste scherm. Twijfel je, lees dan abonnement of eenmalige aankoop voor een iOS-app.
5. Wat kun je doen zonder account? Als je vroeg beslist wat toegankelijk is zonder registratie, hoef je de onboarding niet opnieuw te bouwen.
6. Welke gegevens moeten een nieuwe telefoon overleven? Deze vraag bepaalt of je een backend zoals Supabase nodig hebt, of dat alles op het toestel kan blijven.
7. Alleen iOS, of iOS en Android? Mijn advies als beginner: eerst iOS. Waarom, lees je in iOS- en Android-app tegelijk.
8. Wat valt expliciet BUITEN de eerste versie? Het nuttigste deel van het document. Het kapt discussies af voordat ze ontstaan, met jezelf en met de AI.
9. Hoe weet je dat het werkt? Eén signaal, meetbaar in de weken na de lancering: gestarte gratis proefperiodes, abonnees, gebruikers die terugkomen.
10. Wat zijn je echte beperkingen? De tijd die je er per week in kunt steken, je apparatuur, en je Apple Developer-account, dat 99 $ per jaar kost. Geen Mac? Geen probleem, zoals ik uitleg in een iOS-app publiceren zonder Mac.

De template om te kopiëren

Kopieer deze template naar een notitie of een tekstbestand in de root van je project en vul elke regel in.

• Werknaam van de app: …
• Voor wie: iemand die … op het moment dat …
• Opgelost probleem, in één zin: …
• Hoofdfunctie van versie 1: …
• Wat de gebruiker ziet als hij de app voor het eerst opent: …
• Verdienmodel: abonnement / eenmalige aankoop / gratis, en wat betaald is: …
• Zonder account kun je: …
• Gegevens die tussen twee telefoons bewaard blijven: geen / …
• Platform: eerst iOS (Android later als de cijfers meevallen)
• Buiten versie 1: …, …, …
• Successignaal: …
• Stack: React Native, Expo, Supabase als er accounts nodig zijn, RevenueCat voor abonnementen
• Beperkingen: … uur per week, Apple Developer-account wel of niet aangemaakt, wel of geen Mac
• Apps waarvan ik de ervaring goed vind, en waarom: …

Voeg drie tot vijf screenshots van apps die je mooi vindt toe, met een woord over wat je aanspreekt. Dat zegt meer dan een huisstijlgids, voor jou en voor de AI.

Een programma van eisen is geen verlanglijst. Het is een lijst van genomen beslissingen.

Voorbeeld: de ingevulde pagina voor een fictieve app

Om te laten zien hoeveel detail je nodig hebt, hier de template ingevuld voor een app die ik voor dit voorbeeld verzonnen heb: een studietimer.

• Voor wie: een student die 's avonds alleen studeert en na tien minuten afhaakt.
• Probleem: hij houdt een studiesessie niet vol zonder zijn telefoon te pakken.
• Hoofdfunctie: een getimede sessie starten en zijn reeks volgehouden dagen zien.
• Eerste scherm: één knop om een sessie te starten.
• Verdienmodel: abonnement voor gedetailleerde statistieken, basissessie gratis.
• Zonder account: alles, behalve de back-up tussen twee telefoons.
• Buiten versie 1: groepsmodus, ranglijst met vrienden, widgets, Android-versie.
• Successignaal: gebruikers die meerdere dagen achter elkaar terugkomen.

Let op wat er bewust ontbreekt: geen lijst van twintig schermen, geen vastgelegde kleuren, geen architectuur. Die keuzes komen tijdens het bouwen, en met de pagina check je of ze de hoofdfunctie blijven dienen.

Je programma van eisen gebruiken om AI te sturen

Hier levert je pagina het meeste op. Een AI die zonder context codeert, gokt, en gokt vaak op een andere app dan de jouwe.

Zet de pagina in de vaste context van het project. Claude Code leest een bestand CLAUDE.md in de root, Cursor heeft eigen regelbestanden. Plak je programma van eisen erin, samen met je stack. Elke vraag vertrekt dan vanuit dezelfde basis.

Verwijs naar het deel "buiten versie 1" als de AI te veel doet. Assistenten stellen graag extra functies voor: een donkere modus, delen, een notificatie. Je lijst met uitsluitingen geeft je een kant-en-klaar antwoord: nu niet.

Vraag om een plan dat de pagina respecteert. Schrijf voor een grote klus: "dit is mijn programma van eisen, stel een plan voor de hoofdfunctie voor, nog niet coderen". Je ziet meteen of het plan afwijkt van wat je besloten hebt.

Laat de AI de pagina nalezen, niet alleen de code. Vraag: "welke vragen in dit programma van eisen zijn vaag of tegenstrijdig?". Een onderschat gebruik van AI, dat je weken werk in de verkeerde richting bespaart.

Wil je verder, dan beschrijf ik de valkuilen en controles in een iOS-app maken met AI.

Beslissingen omzetten in acceptatiecriteria

Een hoofdfunctie moet een waarneembaar resultaat hebben. Voor de fictieve timer uit dit voorbeeld is "de timer werkt" te vaag. Schrijf liever: "Ik start een sessie, de resterende tijd wordt getoond, ik kan hem stoppen en de laatst voltooide sessie terugvinden nadat ik de app opnieuw heb geopend." Beslis apart of de timer moet doorlopen als het scherm vergrendeld is: die keuze kan het technische werk veranderen.

Zet bij elke functie drie regels: actie, verwacht resultaat, bewijs. Het bewijs kan een geautomatiseerde test zijn voor een berekening, of een controle op een toestel voor een flow. Noteer ook wat niet getest is. Zo'n tabelletje voorkomt dat je een af scherm verwart met een functie die klaar is voor gebruik.

Hier een ingevulde tabel voor onze fictieve timer. Het zijn criteria om te controleren, geen tests die al geslaagd zijn:

Beslissing uit de afbakening	Te testen	Verwacht resultaat
De basissessie is toegankelijk zonder account	De app installeren en een sessie starten zonder te registreren	Geen registratieformulier blokkeert het starten
Een afgebroken sessie telt niet mee in de reeks	Een sessie voor het einde stoppen en dan de geschiedenis openen	Er wordt geen voltooide sessie toegevoegd
De geschiedenis blijft op het toestel	Een sessie afronden, de app sluiten en opnieuw openen	De sessie verschijnt één keer, met de juiste duur
De basistimer werkt zonder netwerk	Vliegtuigmodus aanzetten en een sessie afronden	De timer en de lokale opslag blijven bruikbaar
De gedetailleerde statistieken zijn betaald	De statistieken openen zonder abonnement	Het aanbod verschijnt; de basissessie blijft toegankelijk

Onderwerpen die nog vaag zijn, worden beslissingen die je moet nemen. Bijvoorbeeld: wat gebeurt er als de gebruiker tijdens een sessie het scherm vergrendelt of de tijd van de telefoon aanpast? Laat de agent dat niet stilzwijgend kiezen. Schrijf het gewenste gedrag op en voeg het geval toe aan de tabel. Om deze acceptatietest op een echte installatie te organiseren, gebruik je de gids je iPhone-app testen met TestFlight.

Beslissen wat eruit moet als de eerste versie uitdijt

Neem elke functie door en stel één vraag: "Kan de gebruiker zonder deze functie nog het beloofde resultaat bereiken?" Voor onze timer kan een ranglijst met vrienden wachten. Een voltooide sessie terugvinden is nodig als je een reeks dagen belooft. Een abonnementsscherm wordt pas nodig als je de statistieken in deze versie daadwerkelijk verkoopt.

Noteer de beslissing en de reden in het logboek van de downloadbare template. Zo kun je na tests op die keuze terugkomen, zonder het waarom van de oorspronkelijke scope kwijt te raken. De tutorial een app maken met Claude Code laat daarna zien hoe je deze afbakening omzet in beperkte, controleerbare opdrachten.

Voor een praktijkvoorbeeld: TradaZen veranderde van scope na de publicatie. De afbakening dient om een eerste meetbare versie uit te brengen, en daarna met echte feedback over de volgende te beslissen.

De valkuil van de functiecatalogus

De natuurlijke reflex is alles op te sommen wat de app "moet kunnen": de kaart, de chat, de notificaties, het verwijsprogramma, de offlinemodus. Die catalogus is het betrouwbaarste teken van een project dat nooit af komt, om een simpele reden: elke functie die je voor de lancering toevoegt, stelt het moment uit waarop echte gebruikers je vertellen wat ertoe doet.

Een goede eerste versie doet één ding, en doet dat goed. Pas wel op voor het omgekeerde: Apple eist dat een app meer is dan een verpakte website, volgens regel 4.2 van de App Review Guidelines. Eén hoofdfunctie, ja; een lege huls, nee: dat is de reden achter guideline 4.2.

Wat er niet in een programma van eisen voor een mobiele app hoort

• Een complete huisstijlgids. Een paar referentiescreenshots zijn in het begin genoeg.
• Een planning per dag. Je hebt nog niet de informatie om die aan te houden. Een weekdoel volstaat.
• Een gedetailleerde technische architectuur. Kies een beproefde stack en laat de details tijdens het bouwen beslissen.
• Functies "voor later" tussen de rest. Die horen allemaal in het deel buiten versie 1.

Wanneer werk je je programma van eisen bij?

Lees het aan het begin van elke werkweek terug. Werk het alleen bij als een beslissing om een echte reden verandert: een test op je iPhone die laat zien dat een scherm niet werkt, feedback van een tester, een Apple-beperking die je onderweg ontdekt. Pas je het elke dag aan, dan bakent het niets meer af.

Zodra de eerste versie gepubliceerd is, wordt de pagina de basis voor de volgende: wat buiten versie 1 viel, komt naar boven, gesorteerd op wat de cijfers je vertellen. Het complete overzicht van idee tot publicatie staat op de pagina een iPhone-app maken.

Van de pagina naar de gepubliceerde app

Heb je de tien vragen beantwoord, dan heb je al het werk gedaan dat veel projecten overslaan. Daarna ga je de hoofdfunctie bouwen, op je iPhone testen, de abonnementen koppelen en het dossier voor Apple voorbereiden.

Dat traject volgt de iOS Kit, in vier stappen in je eigen tempo: de eerste helpt je de app te kiezen die geld kan opleveren, het publiek en de prijs, en je programma van eisen is daar het startpunt van.

Weet je niet of je idee klaar is om op één pagina te passen? De gratis diagnose vertelt je wat je project nu blokkeert en welke stap je het eerst aanpakt. De homepage laat daarna zien hoe je vanuit deze afbakening een mobiele app maakt met Claude Code.

Ik beloof je geen inkomsten en geen publicatie: Apple keurt goed, en de markt beslist over de rest. Zonder de kit is deze template genoeg om te beginnen.

Veelgestelde vragen

Hoe schrijf je een programma van eisen voor een mobiele app?

Houd je programma van eisen op één pagina: tien vragen, een of twee zinnen per antwoord. Ze gaan over het publiek, het probleem, de hoofdfunctie, het verdienmodel, wat er gebeurt zonder account, de gegevens die bewaard moeten blijven, het platform, wat buiten de eerste versie valt, het successignaal en de beperkingen. Is een antwoord langer dan twee zinnen, dan is de beslissing vaak nog niet genomen.

Welke software gebruik je om een programma van eisen voor een app te schrijven?

Een gewone notitie of een tekstbestand in de root van je project: je kopieert de template erin en vult elke regel in. Je kunt ook de template en de validatietabel downloaden (.md), zonder je aan te melden. Om een AI te sturen, zet je het daarna in het contextbestand van je project.

Heb je een programma van eisen van 40 pagina's nodig voor een app?

Nee, niet als je je eigen app maakt: één pagina is genoeg. De templates van 40 pagina's die je online vindt, zijn geschreven voor een klant die een app bestelt bij een bureau en een contractueel document nodig heeft. Jij beslist en bouwt zelf: je pagina dient om beslissingen te nemen voor je gaat coderen en om de AI context te geven.

Hoe geef je je programma van eisen aan een AI die codeert?

Zet de pagina in de vaste context van het project: Claude Code leest een bestand CLAUDE.md in de root, Cursor heeft eigen regelbestanden. Verwijs naar het deel "buiten versie 1" als de AI te veel doet. Vraag voor een grote klus om een plan dat de pagina respecteert, zonder meteen te coderen.

Hoe controleer je of een functie aan het programma van eisen voldoet?

Zet bij elke functie drie regels: de actie, het verwachte resultaat en het bewijs. Het bewijs kan een geautomatiseerde test zijn voor een berekening, of een controle op een toestel voor een flow. Noteer ook wat niet getest is, zodat je een af scherm niet verwart met een functie die klaar is voor gebruik.

Wat zet je niet in een programma van eisen voor een app?

Vier dingen om te vermijden: een complete huisstijlgids, een planning per dag, een gedetailleerde technische architectuur, en functies "voor later" tussen de rest. Een paar referentiescreenshots zijn in het begin genoeg, en voor de planning volstaat een weekdoel. De functies voor later horen allemaal in het deel buiten versie 1.