Gebruik een één-pagina appspecificatie om een vaag idee om te zetten in heldere prompts voor Planning Mode: gebruikers, jobs-to-be-done, entiteiten en randgevallen.
Een vaag idee is prima om bij weg te dromen. Om te bouwen is het lastig.
Als je een AI-builder vraagt om “een app om gewoontes bij te houden” zonder meer details, moet die gaan raden wat je bedoelt. Die aannames veranderen van prompt tot prompt, dus de app verandert ook. Je krijgt schermen die niet bij elkaar passen, data die halverwege de bouw anders genoemd wordt, en features die verschijnen, verdwijnen en later in een andere vorm weer terugkomen.
Die inconsistentie komt meestal op een paar plekken naar voren:
"Planning Mode" is een eenvoudige pauze vóór het bouwen. Je schrijft de beslissingen op die de AI anders zou verzinnen. Het punt is consistentie: één set keuzes waar UI, backend en database zich aan kunnen houden.
Het doel is niet perfectie. Het is een build waarmee je kunt itereren zonder constant een stapel aannames te moeten repareren. Als je later van gedachten verandert, update je één klein spec en bouw je opnieuw met dezelfde logica.
Daarom is een één-pagina appspecificatie-sjabloon waardevol. Het is geen lang PRD en geen weken aan diagrammen. Het is één pagina die vier dingen beantwoordt: wie de gebruikers zijn, wat ze gedaan willen krijgen, welke data er bestaat (in gewone taal), en welke randgevallen of non-goals de eerste versie binnen de perken houden.
Voorbeeld: “Een boekingsapp” wordt veel duidelijker zodra je bepaalt of het voor één salon-eigenaar is of een marktplaats, en of klanten kunnen verzetten, annuleren of niet op komen dagen.
Een één-pagina appspecificatie is een korte notitie die een vaag idee omzet in heldere instructies. Je bent niet het hele product aan het ontwerpen. Je geeft je AI-builder genoeg structuur om steeds dezelfde keuzes te maken.
De pagina heeft vier blokken. Als het niet op één pagina past, heb je waarschijnlijk te veel features voor een eerste build.
Een pagina dwingt nuttige beperkingen af. Het zet je ertoe aan een primaire gebruiker te kiezen, de kleinst mogelijke succesvolle flow te definiëren en vage beloften als “alles ondersteunen” te vermijden. Die beperkingen zorgen ervoor dat een AI-gebouwde app niet van mening verandert tussen schermen.
"Goed genoeg" detail ziet eruit als simpele, toetsbare uitspraken. Als iemand het kan lezen en vragen kan stellen als “Hoe weten we dat dit werkt?”, zit je op het juiste niveau.
Een snelle richtlijn:
Houd de taal eenvoudig. Schrijf regels die je direct in prompts kunt plakken, zoals: “Een manager kan een verzoek goedkeuren of afwijzen, en de aanvrager krijgt een statusupdate.”
Zet een timer op 20 minuten en mik op “duidelijk genoeg om te bouwen”, niet “perfect”. Het doel is gokwerk te verwijderen zodat je AI-builder steeds dezelfde keuzes maakt.
Begin met één zin die antwoordt op: voor wie is het, en welke uitkomst krijgen ze?
Voorbeeld: “Een mobiele app voor hondenbezitters om wandelingen en dierenartsbezoeken op één plek bij te houden.”
Als je het niet in één zin kunt zeggen, is het idee waarschijnlijk twee apps.
Noem vervolgens 1 tot 3 gebruikerstypen als echte mensen, niet abstracte rollen. “Owner”, “Vet” en “Family member” is duidelijker dan “User A.” Voor elk type voeg je één korte regel toe over wat hen het meest kan schelen.
Schrijf daarna 3 tot 7 jobs-to-be-done in het format: “When [situatie], I want to [actie], so I can [resultaat].” Hou ze toetsbaar. “When I finish a walk, I want to log distance and notes, so I can spot patterns” is duidelijker dan “track health.”
Definieer nu je entiteiten en sleutelvelden zonder database-taal. Denk “dingen die de app onthoudt.” Voor de hondenapp: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). Als een veld niet gebruikt wordt in een scherm of job, laat het weg.
Sluit af met twee korte blokken: randgevallen en non-goals. Randgevallen zijn vervelend maar vaak (“geen internet”, “twee honden met dezelfde naam”). Non-goals zijn dingen die je nog niet bouwt (“geen betalingen”, “geen sociaal feed”).
Zet ten slotte elk blok om in prompts die je builder kan volgen. Het consistent houden van de structuur (doel, gebruikers, jobs, entiteiten, randgevallen) helpt het systeem schermen, data en flows te genereren die overeenkomen.
Als je spec “voor iedereen” zegt, moet een AI-builder raden wat eerst gebouwd wordt. In een één-pagina spec definieer je gebruikers op basis van intentie (wat ze kwamen doen), niet demografische kenmerken. Intentie leidt tot duidelijke keuzes over schermen, data en permissies.
Noem 2–4 gebruikerstypes, elk met één hoofddoel. Goede voorbeelden zijn “Klant die een bestelling plaatst”, “Teamlid dat bestellingen uitvoert” en “Manager die prestaties bekijkt.” Vage voorbeelden zijn “18–35”, “drukke professionals” of “admins” (tenzij je zegt wat ze beheren).
Gebruik elke keer dezelfde zinsstructuur: “When..., I want to..., so I can...”. Dit houdt de app op uitkomsten gefocust en geeft de AI-builder stabiele, toetsbare vereisten.
Hier zijn realistische JTBD-voorbeelden met een duidelijke definitie van “klaar”:
Succescriteria zijn belangrijk omdat ze de vaagheid van “ziet er goed uit” wegnemen. Ze vertellen de builder wat de UI moet toestaan en wat de backend moet opslaan.
Schrijf geen volledig beveiligingsplan. Zeg gewoon wie wat kan doen, in gewone taal.
Voorbeeld: “Members kunnen hun eigen items aanmaken en bewerken. Managers kunnen elk item bewerken en status wijzigen. Owners kunnen gebruikers en facturatie beheren.”
Als je een planningsstap in een tool als Koder.ai gebruikt, worden deze gebruikerstypen, JTBD-regels en permissies betrouwbare inputs. Ze voorkomen ook dat de AI extra rollen verzint of verantwoordelijkheden door elkaar haalt op schermen.
Entiteiten zijn de “dingen” waar je app rekening mee houdt. Als je ze duidelijk benoemt, kan je AI-builder schermen, formulieren en een database maken die allemaal overeenkomen. Dit voorkomt mismatchende velden en willekeurige extra features.
Begin met het opsommen van je kern-namen. Als de app “projecten beheren” is, zijn je zelfstandige naamwoorden Project, Task en Comment. Als het “kapsels boeken” is, heb je Booking, Service, Customer en Staff.
Voor elke entiteit schrijf je velden in alledaagse woorden, niet database-termen. Stel je voor wat iemand in een formulier zou typen.
Als je een veld niet in één zin kunt uitleggen, is het waarschijnlijk te gedetailleerd voor de eerste versie.
Beschrijf hoe entiteiten verbinden met simpele zinnen:
“Een gebruiker kan veel projecten hebben.” “Elke taak hoort bij één project.” “Een comment hoort bij een taak en heeft één auteur.”
Dit geeft de builder genoeg structuur om consistente lijsten, detailpagina’s en filters te genereren.
Voeg een paar dataregels toe die rommelig gedrag voorkomen:
Snijd tenslotte scope door te benoemen wat je nog niet opslaat. Voorbeeld: “Geen bestandsbijlagen in v1,” of “Track staff schedules nog niet, alleen boekingen.” Die uitsluitingen zijn belangrijk omdat ze voorkomen dat de app in de verkeerde richting groeit.
Een één-pagina spec werkt het beste als de eerste versie een kleine, stabiele set schermen heeft. Als je probeert elk scherm te ontwerpen dat de app ooit nodig kan hebben, blijft je AI-builder raden en zal de UI tussen builds blijven afwijken.
Begin met het benoemen van de minimale schermen die iemand in staat stellen de hoofdtaak te voltooien. Voor de meeste MVPs zijn 3 tot 6 schermen genoeg:
Schrijf daarna het happy path als een kort verhaaltje van begin tot eind.
Voorbeeld: “Gebruiker logt in, komt op de lijst, zoekt, opent een item, bewerkt één veld, slaat op en keert terug naar de lijst.”
Noem voor elk scherm de belangrijkste acties in gewone woorden. Vermijd “doe alles” schermen. Kies de 2 tot 4 acties die het meest relevant zijn, zoals maken, bewerken, zoeken, exporteren of archiveren.
Bepaal ook wat snel moet zijn en wat “goed genoeg” kan zijn. “Snel” betekent meestal dat de lijst snel opent, zoeken reageert vlug en opslaan direct aanvoelt. “Goed genoeg” kan export zijn die een paar seconden duurt, basisanalytics of eenvoudige instellingen.
Leg tenslotte rollen en toegang vast in één regel per rol:
Dit houdt schermen voorspelbaar, voorkomt permissie-verrassingen en vermindert herschrijvingen later.
De meeste herschrijvingen gebeuren om één reden: de app werkt prima in het happy path, maar faalt zodra het echte leven zich aandient.
Een goede één-pagina spec maakt ruimte voor randgevallen en non-goals, en die kleine ruimte bespaart uren.
Begin met elke job-to-be-done en vraag: wat kan er misgaan? Houd het niet technisch, maar duidelijk. Je verwijdert ambiguïteit zodat de builder elke keer dezelfde beslissing neemt.
Veelvoorkomende randgevallen die het waard zijn om op te schrijven:
Bepaal daarna de reactie. Wees specifiek: “Blokkeer de actie en toon een duidelijke melding”, “Sta opslaan als concept toe”, of “Probeer één keer opnieuw, toon daarna een knop om het nogmaals te proberen.” Die regels vertalen direct naar consistente prompts.
Voeg privacy- en veiligheidsexpectaties toe in één of twee regels. Bijvoorbeeld: “Verzamel alleen de minimale data die nodig is”, “Gebruikers kunnen hun account en alle persoonlijke data verwijderen”, en “Privé-items standaard verbergen.” Als je app user-generated content heeft, noteer wat te doen met meldingen en spam, zelfs als het simpel is in v1.
Schrijf tenslotte non-goals om scope creep te stoppen. Kies de grootste verleidelijke features die je nog niet doet.
Voorbeelden van duidelijke non-goals:
Een kort voorbeeld: als de taak “Maak een event”, definieer wat er gebeurt wanneer de datum in het verleden ligt, de titel leeg is of hetzelfde event twee keer wordt aangemaakt. Die duidelijkheid voorkomt de volgende rebuild.
De snelste manier om consistente resultaten te krijgen is elk blok van je één-pagina spec om te zetten in een kleine, directe prompt. Zie het als een stapel kaarten die de builder op volgorde kan afwerken, in plaats van één grote vage opdracht.
Zet elk blok (Gebruikers, Jobs, Entiteiten, Schermen, Randgevallen, Non-goals) om in één instructie met duidelijke zelfstandige naamwoorden en werkwoorden. Vermijd meningen als “maak het schoon” tenzij je ook uitlegt wat “schoon” betekent.
Gebruik een twee-staps cyclus: bouw eerst, valideren daarna.
Voeg een korte definitie van voltooiing toe zodat de builder weet wanneer te stoppen. Maak het meetbaar:
Voeg alleen beperkingen toe wanneer ze echt belangrijk zijn: vereiste apparaten (mobile-first), verplichte authenticatie (admin-only acties) of een vereist stack (zoals React frontend, Go backend, PostgreSQL) als je platform dat verwacht.
Wanneer je wijzigingen wilt, verwijs naar het specblok, niet naar de code.
Voorbeeld: “Werk het Entiteiten-blok bij: voeg ‘Subscription’ toe met velden X en Y. Regenerate daarna alleen de getroffen API’s en schermen, en voer de validatiestap opnieuw uit.”
Die aanpak houdt het plan stabiel terwijl je veilig kunt itereren.
Stel je wilt een eenvoudige afspraak-herinnerings-app voor een kleine salon. Het doel is geen volledig boekingssysteem. Het is een lichte plek om afspraken op te slaan en herinneringen te sturen.
Hier is hoe een ingevuld één-pagina appspecificatie eruit kan zien.
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
Zet dit vervolgens om in een promptbundle die je kunt plakken in Planning Mode app-building. Houd het strikt zodat de builder steeds dezelfde keuzes maakt.
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
Rommelige output begint meestal met een vage spec en een verlanglijstje met features. Een AI-builder doet wat je vraagt, maar kan je gedachten niet lezen. Kleine gaten worden grote verschillen tussen schermen en flows.
Deze valkuilen breken consistentie het vaakst, en het één-pagina specsjabloon lost ze op:
Als je Planning Mode in Koder.ai gebruikt, zijn deze basics nog belangrijker omdat het plan de bron wordt voor herhaalde prompts. Duidelijke jobs, klein datamodel, expliciete permissies en toetsbare succesregels houden elk nieuw scherm in lijn met de rest.
Controleer je één-pagina appspecificatie voordat je bouwt. Het doel is de gaten te dichten die een AI-build dwingen te raden. Die gissingen worden herschrijvingen.
Een snelle completeitscheck:
Als je een simpele score wilt gebruiken, geef elk gebied 0–2:
Streef naar minstens 7 van 10 voordat je iets genereert. Als Entiteiten of Randgevallen onder de 2 scoren, los die dan eerst op. Zij veroorzaken de meeste churn.
Na de eerste build, toets de app tegen elk job-to-be-done en markeer mismatches. Maak een snapshot vóór elke wijziging. Als een nieuwe iteratie dingen slechter maakt, rollback en probeer een kleinere wijziging.
Als je Koder.ai (koder.ai) gebruikt, is Planning Mode een praktische plek om deze één-pagina spec als “source of truth” te bewaren en alleen te regenereren wat veranderde in plaats van alles handmatig te herschrijven.
Houd de spec actueel terwijl je verdergaat. Wanneer je een wijziging accepteert in de app, update dan dezelfde dag de spec. Wanneer je een wijziging weigert, schrijf op waarom, zodat de volgende prompt consistent blijft.
Planning Mode is een korte pauze waarin je belangrijke beslissingen opschrijft voordat je schermen en code genereert. Het doel is consistentie: dezelfde gebruikers, stromen en datanamen in UI, backend en database, zodat je niet telkens opnieuw hoeft te bouwen omdat het systeem nieuwe aannames maakt.
Begin met één zin doel, en vul daarna vier blokken in:
Als het niet op één pagina past, schrap functies voor v1.
Houd het praktisch en intent-gebaseerd. Noem een paar gebruikerstypen en wat ze proberen te bereiken.
Voorbeeld: “Owner/Staff die afspraken aanmaakt” is duidelijker dan “Admin.” Als je niet binnen één regel kunt uitleggen wat een rol doet, is die rol waarschijnlijk te vaag.
Gebruik een strikte patroon zodat elke job testbaar is:
Voeg daarna een korte definitie van voltooiing toe (wat moet worden opgeslagen/geüpdatet/zichtbaar zijn). Dit voorkomt dat de builder extra stappen of willekeurige schermen bedenkt.
Noem de “dingen die de app onthoudt” in gewone taal en geef elk 3–7 velden die je echt op schermen gebruikt.
Voorbeeld: Appointment: starttijd, duur, status, service, client. Als een veld niet gebruikt wordt door een job of scherm, laat het weg voor v1.
Schrijf relaties als eenvoudige zinnen:
Voeg een paar basisregels toe (vereiste velden, unieke velden, defaults). Dat is meestal genoeg om lijsten, formulieren en filters consistent te houden.
Een goed uitgangspunt is 3 tot 6 schermen die de hoofdtaak end-to-end afhandelen:
Schrijf ook één “happy path”-verhaal (start → actie → opslaan → bevestiging) zodat de stroom niet afwijkt.
Randgevallen zijn waar echt gebruik het gelukkige pad breekt. Schrijf de top 5–10 die het meest waarschijnlijk zijn:
Voor elk geval: geef het verwachte gedrag aan (blokkeer + boodschap, opslaan als concept, herproberen, enz.).
Zet elk blok om in een korte instructie die de builder kan uitvoeren en verifiëren.
Een eenvoudige volgorde:
Dat voorkomt dat je leunt op één grote vage prompt die makkelijk verkeerd wordt geïnterpreteerd.
Werk eerst de spec bij, en genereer daarna alleen wat veranderd is.
Voorbeeld: “Voeg entiteit Subscription toe met velden X/Y; werk de beïnvloede schermen en API’s bij; controleer opnieuw tegen de spec.”
Het spec als bron van waarheid houden voorkomt verspreide, inconsistente wijzigingen.