Leer hoe je beperkingen en niet-doelen in app-specificaties schrijft zodat herwerk snel afneemt. Gebruik een eenvoudig format voor vaste stack, budget, deadline en wat kan veranderen.
Herwerk gebeurt wanneer je iets bouwt dat werkt, maar niet het juiste is voor het project. Teams bouwen schermen opnieuw, herschrijven logica, migreren data of herbouwen een feature omdat een belangrijke beslissing laat opduikt.
Dat merk je vaak op bekende manieren: een flow wordt herbouwd omdat de verkeerde gebruikersrollen werden aangenomen; schermen worden opnieuw ontworpen omdat mobiele ondersteuning werd verwacht maar nooit genoemd; het datamodel verandert omdat “we auditgeschiedenis nodig hebben” pas na versie één verschijnt; een integratie wordt gewisseld omdat een klant geen third-party dienst kan gebruiken; of de app moet van hosting veranderen vanwege compliance of regioregels.
Ontbrekende beperkingen zorgen later voor verrassende beslissingen. Als een spec zegt “bouw een CRM,” laat dat tientallen vragen open: wie gebruikt het, welke platforms zijn belangrijk, welke beveiligingsregels gelden, wat moet buiten scope blijven, wat zijn het echte budget en de echte tijdslijn. Als de antwoorden pas komen nadat er code is, betaalt het project dubbel: eenmaal om te bouwen en nogmaals om het ongedaan te maken.
Een eenvoudig voorbeeld: een oprichter vraagt om “afspraken + herinneringen.” Week één worden e-mailherinneringen opgeleverd. Week twee zeggen ze dat ze SMS nodig hebben, maar SMS is niet toegestaan in hun land of het gaat het budget te boven. Nu wordt het herinneringssysteem opnieuw ontworpen, schermen veranderen en testen begint opnieuw. Het herwerk werd niet veroorzaakt door slecht coderen. Het werd veroorzaakt door late beperkingen.
Het doel is om heen-en-weer te verminderen vóórdat er ook maar één regel code wordt geschreven of gegenereerd. Of je nu handmatig codeert of een chat-gebaseerde builder gebruikt, de output volgt alleen de regels die je geeft. Als de regels laat komen, verschuift het werk en moet je het opnieuw doen.
Dit gaat niet over het schrijven van een lang document. Een lichte spec kan toch strikt zijn waar het telt. Vroeg moet het antwoord geven op:
Wanneer beperkingen en niet-doelen eerst worden opgeschreven, werken ze als vangrails. Je krijgt minder verrassingen, minder herbouw en duidelijkere beslissingen vanaf dag één.
Beperkingen zijn vaste beslissingen waar je project mee moet leven. Negeer ze en je doet werk twee keer, omdat je iets bouwt dat niet kan worden opgeleverd.
Niet-doelen zijn expliciete keuzes om iets niet te bouwen. Sla ze over en de spec groeit stilletjes terwijl mensen “kleine” extra’s toevoegen. Zo eindig je met het opnieuw doen van schermen, flows en datamodellen.
Een snelle regel: beperkingen beperken hoe je bouwt; niet-doelen beperken wat je bouwt.
Een beperking is een must die niet verandert zonder een echte beslissing (en een afweging).
Voorbeelden:
Als een beperking echt is, schrijf het dan als een zin waar je niet over kunt discussiëren. Als iemand “misschien” zegt, is het nog geen beperking.
Een niet-doel is een expliciet “we doen dit niet”, zelfs als het nuttig klinkt. Het beschermt de eerste release.
Voorbeelden:
Niet-doelen zijn geen negativiteit. Ze voorkomen dure omwegen. Bijvoorbeeld: “geen aangepaste rollen in v1” kan weken aan permissie-edgecases besparen die een database- en UI-ontwerp zouden forceren.
Voordat je pagina’s met details schrijft, formuleer één zin die het project vastlegt. Het houdt iedereen op één lijn wanneer er afwegingen komen.
Een goede one-liner beantwoordt: voor wie is dit en wat is de belangrijkste taak?
Voorbeelden one-liners:
Voeg daarna een korte succesdefinitie toe: 3 tot 5 uitkomsten die een echte gebruiker moet bereiken wanneer het project klaar is. Schrijf ze als gebruikersresultaten, niet als features.
Voor het voorbeeld met bijles:
Als je nog geen metrics hebt, beschrijf succes in woorden. “Snel” is vaag, maar “voelt snel op een telefoon” is nog steeds bruikbaar. “Makkelijk” is vaag, maar “geen onboardinggesprek nodig” is duidelijker. Je kunt later cijfers toevoegen.
Houd deze sectie kort. Het wordt de context voor alles wat volgt: wat moet waar zijn, wat mag niet gebeuren en wat mag veranderen.
Herwerk begint vaak wanneer planning en beslissingsproces alleen in iemands hoofd leven. Zet de projectbeperkingen in de spec voordat je schermen en features beschrijft.
Schrijf ze als eenvoudige, toetsbare uitspraken:
Een eenvoudig voorbeeld:
“Eerste release moet live zijn op 30 mei. Het bevat login, een basis klantlijst en één maandrapport. Geen integraties in v1. Budget is beperkt tot €8.000 inclusief hosting voor de eerste maand. Reviews binnen 24 uur op weekdagen. Producteigenaar is Sam, die scope-wijzigingen goedkeurt.”
Snelheid van feedback verdient zijn eigen regel omdat het bepaalt hoe veilig je kunt bewegen. Als stakeholders slechts één keer per week beoordelen, moet de spec kleinere releases en minder edgecases aanmoedigen.
Kies een review-cadans die bij de realiteit past: feedback dezelfde dag, 24–48 uur op weekdagen, wekelijkse reviewmeeting alleen, of (zeldzaam) “geen feedback nodig”.
Als je technische beperkingen niet vroeg vastlegt, vullen mensen de gaten met aannames. Zo herwerken teams later schermen, migraties of integraties nadat het werk al begonnen is.
Begin met te zeggen wat vaststaat en wat slechts een voorkeur is. “Voorkeur voor React” is iets anders dan “moet React zijn omdat we een in-house componentbibliotheek gebruiken.” Eén zin per beslissing is genoeg.
Wees expliciet over de hele app: web, backend, database en mobiel. Als een deel flexibel is, zeg dat en voeg een grens toe (bijv. “mobiel is web-only in v1”).
Een eenvoudige manier om het te schrijven:
Noem daarna integraties die onvermijdelijk zijn. Benoem systemen (betalingen, e-mail, analytics, CRM) en zet harde limieten. Voorbeelden: “Moet Stripe gebruiken voor betalingen,” “E-mail moet via onze bestaande provider,” “Analytics mag geen persoonsgegevens tracken.” Als authenticatie vastligt (SSO, Google-login, passwordless), vermeld dat.
Hostingkeuzes veranderen de architectuur. Schrijf waar de app moet draaien en waarom: “Moet in Duitsland draaien,” “Data moet in de EU blijven,” of “Mag wereldwijd draaien.”
Als je compliance-eisen hebt, maak ze concreet: bewaartermijn, verwijderregels en auditbehoeften.
Voorbeeld: “Bewaar records 7 jaar, verwijder binnen 30 dagen na een geverifieerd verzoek, houd een auditlog bij van wie een record heeft bekeken, en deploy alleen in het land waar patiënten wonen.” Deze regels voorkomen late verrassingen vlak voordat je gaat opleveren.
Niet-doelen zijn de vangrails van een spec. Ze zeggen wat je niet bouwt, niet ondersteunt of niet probeert te perfectioneren in de eerste release. Dit is één van de snelste manieren om verrassingen te verminderen, omdat veel “kleine” verzoeken later komen en stilletjes het hele plan veranderen.
Een goed niet-doel is specifiek genoeg zodat een teamgenoot scope creep in één zin kan herkennen. Het moet ook tijdgebonden zijn. “Niet in v1” is duidelijker dan “we doen dit niet.”
Begin met features die mensen vaak vanzelfsprekend vinden. Voor een eenvoudige boekingsapp kan dat zijn:
Dit zijn geen slechte features. Ze zijn duur. Ze opschrijven houdt de eerste release gefocust.
Meld ook “detail”-items die veel knock-on werk veroorzaken: rollen, permissies en edge-case-workflows. “Geen aangepaste rollen. Alleen twee rollen: Owner en Member.” Die ene regel kan weken schelen.
Teams vergeten vaak niet-doelen die geen features zijn. Die komen later als pijnlijk herwerk.
Bepaal waarop je niet optimaliseert. Bijvoorbeeld: “We optimaliseren niet voor 1M gebruikers. We gaan uit van maximaal 500 wekelijkse actieve gebruikers in v1.”
Noem ook wat je niet ondersteunt, zodat testen realistisch blijft: “Geen Internet Explorer,” “Geen tablet-specifieke layouts,” of “Login alleen via e-mail en wachtwoord (geen SSO, geen magic links).”
Een spec voelt veiliger als hij kleine beslissingen laat evolueren. Als je alleen opschrijft wat vaststaat, wordt elk nieuw idee een debat. Een korte ‘mag veranderen’-lijst geeft ruimte om het product te verbeteren zonder het hele plan te herstarten.
Wees praktisch. Dek wat je verwacht te leren nadat je een werkende versie ziet, niet grote nieuwe features. Veelvoorkomende flexibele items zijn UI-tekst, kleine flow-aanpassingen, kolommen in rapporten, naamgeving (rollen, statussen, categorieën) en basislayoutkeuzes.
Bepaal daarna hoe veranderingen worden geaccepteerd. Zonder een eenvoudige goedkeuringsregel veranderen “snelle tweaks” in stille scope creep.
Een simpele workflow die voor de meeste kleine teams werkt:
De sleutelregel: flexibele wijzigingen mogen geen vaste beperkingen breken. Als je stack React + Go + PostgreSQL is, kan een “mag veranderen”-verzoek niet worden “laten we de backend wisselen.” Als de deadline vast is, kan “mag veranderen” niet betekenen dat je een module toevoegt die twee weken extra nodig heeft.
Voeg één afwegingsnota toe waar iedereen het mee eens is. Voorbeeld: “Als we een nieuwe gebruikersrol met aangepaste permissies toevoegen, schuiven we geavanceerde rapportage naar fase 2.”
Een goede spec begint met het beperken van opties, niet met het uitbreiden ervan. Dit format dwingt je om de regels te schrijven voordat iemand begint met bouwen.
Gebruik dit als kop in je document:
SPEC v0.1 (date)
Owner:
Reviewers:
1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]
2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]
3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]
4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]
5) Open questions
- Q: [question]
Owner: [name]
Due: [date]
6) Lock rule
- After review: changes require: [what approval looks like]
(Zorg dat dit codeblok onvertaald blijft; het is bedoeld als sjabloon.)
De meeste verrassingen zijn geen pech. Ze ontstaan omdat de spec ruimte laat voor verschillende interpretaties.
Een veelvoorkomende valkuil is doelen en oplossingen door elkaar halen. Teams springen te snel naar schermen en workflows zonder eerst op te schrijven wat vaststaat (deadline, budget, tech stack) en wat uit scope is. Het resultaat is een mooi UI-plan dat niet in de beperkingen past.
Een andere valkuil is vage niet-doelen. “Geen extra features” klinkt strikt, maar beschermt niet wanneer iemand vraagt om “nog een rapport” of “een snel adminpaneel.” Goede niet-doelen zijn specifiek en toetsbaar.
Verborgen budgetten of een “zachte” deadline zijn ook scopebommetjes. Als het echte budget €5k is en de spec leest als een €50k-product, bouwt het team het verkeerde ding. Zet die ongemakkelijke cijfers op papier.
Integraties en data-eigendom zorgen ook voor stille verrassingen. Als je zegt “koppel aan Stripe” maar niet definieert welke events, welke velden en wie de data bezit, blijf je dezelfde beslissingen herhalen.
Een laatste valkuil is het veranderen van beperkingen tijdens het bouwen zonder de afweging te benoemen. Overschakelen van “alleen web” naar “web + mobiel”, of van “gebruik Postgres” naar “gebruik wat het goedkoopst is,” verandert het plan. Je kunt dat doen, maar je moet scope, tijdlijn of kwaliteitsverwachtingen bijwerken.
Voeg een korte noot in je spec toe die vijf punten beantwoordt:
Voordat iemand begint met bouwen, moet je zonder te zoeken de “wat staat vast?”-vragen kunnen beantwoorden.
Snelle check:
Als één van deze ontbreekt, zal de eerste build gebeuren, maar de tweede build wordt de echte.
Volgende stappen die momentum houden zonder je vast te zetten in slechte beslissingen:
Als je Koder.ai (koder.ai) gebruikt, helpt “Planning Mode” plus een duidelijke sectie met beperkingen en niet-doelen het platform een eerste draft te genereren die bij je stack, hostingregio en scope past. En als prioriteiten verschuiven, laten snapshots en rollback je wijzigingen testen zonder een stabiele baseline kwijt te raken.
Wanneer deze regels vroeg zijn opgeschreven, worden feature-discussies makkelijker omdat iedereen weet wat vast moet blijven en wat mag bewegen.
Herwerk is wanneer je iets bouwt dat werkt, maar niet verzonden kan worden omdat er later een besluit de regels verandert. Het gebeurt meestal omdat specificaties belangrijke beperkingen niet vroeg genoeg noemen, zodat het team redelijke aannames maakt die achteraf onjuist blijken.
Begin met wat niet kan veranderen zonder een echte afweging, zoals deadline, budgetplafond, hostingregio, vereiste stack en compliance-regels. Voeg daarna een korte sectie met niet-doelen toe zodat mensen scope niet stilletjes uitbreiden met “kleine” extra’s.
Een beperking beperkt hoe je bouwt, bijvoorbeeld “moet in de EU draaien” of “moet React en PostgreSQL gebruiken.” Een niet-doel beperkt wat je bouwt, bijvoorbeeld “geen mobiele app in v1” of “geen aangepaste rollen bij lancering.”
Schrijf het als een zin die getest kan worden, niet als een voorkeur. Als iemand “misschien” kan zeggen en niemand het afdwingt, is het nog geen echte beperking en behandel je het beter als een open vraag.
Kies 3 tot 5 gebruikersresultaten die beschrijven hoe succes eruitziet voor de eerste release, in gewone taal. Resultaten houden het team gefocust op wat gebruikers moeten bereiken, en maken het makkelijker om nee te zeggen tegen features die niet bijdragen aan de eerste release.
Veelvoorkomende verborgen beperkingen zijn mobiele ondersteuning, rollen en permissies, auditgeschiedenis, dataresidency en integraties die een klant niet kan gebruiken. Als je die vroeg benoemt, voorkom je dat je schermen, datamodels of providers laat moet aanpassen.
Wees specifiek en tijdgebonden, zoals “niet in v1” of “we ondersteunen geen tablets.” Een vage niet-doel als “geen extra features” stopt scope creep niet omdat het geen specifieke verzoeken blokkeert.
Schrijf wie veranderingen goedkeurt, hoe snel reviews plaatsvinden en welke cadence je gebruikt om verzoeken te beoordelen. Trage feedback is een echte beperking omdat het beïnvloedt hoe veilig je kunt itereren en hoeveel onzekerheid je aankan.
Noteer ze als open vragen met één eigenaar en een uiterste datum, en begin niet met bouwen aan het getroffen onderdeel totdat het antwoord is vastgelegd. Als je toch moet starten, noteer expliciet de aanname die je gebruikt zodat je het later kunt herzien zonder verwarring.
Gebruik planning om beperkingen en niet-doelen vast te leggen voordat je iets genereert, zodat de eerste draft past bij je stack, regio en scope. Als prioriteiten verschuiven, helpen snapshots en rollback om wijzigingen te testen zonder een stabiele basis kwijt te raken, en broncode-export is handig als je werk elders wilt voortzetten.