Waarom dit stappenplan?
Een app laten maken loopt zelden mis in de codeerfase. Het loopt mis omdat beslissingen worden geforceerd zonder dat de input klaar is. Wireframes terwijl het probleem niet scherp is. Sprint-planning terwijl de scope niet geprioriteerd is. App-store-submission terwijl niemand bedacht heeft wie het account beheert. Elk van die problemen is goedkoop op te lossen in de fase daarvoor, en duur (of onmogelijk) daarna.
Dit stappenplan ordent het proces in tien fases — niet als rigide watervalmodel, maar als checklist voor opdrachtgevers. Per fase: wat het doel is, wat er klaar moet zijn voor u door kunt, en de valkuilen waar we eerstetijders het vaakst over zien struikelen. Bedoeld voor founders, product-owners, marketing- en innovatie-managers en IT-managers die voor het eerst extern laten bouwen. Voor de scope-prioritering verwijzen we naar onze MoSCoW-model uitleg; voor onze aanpak naar de proces-pagina.
Tien fases, elk met een duidelijk "klaar"-criterium. Sla geen fase over om tempo te maken — een overgeslagen fase betaalt zich altijd terug in verloren sprints later in het traject.
Fase 1 — Idee-validatie
Voor er één regel code wordt geschreven moet de hoofdvraag beantwoord zijn: is het probleem dat deze app oplost écht een probleem voor echte mensen, en zijn die mensen bereid hun gedrag te veranderen om het op te lossen? Idee-validatie gaat niet over "geloven in" — het gaat over bewijs verzamelen.
Praat met minimaal acht tot tien mensen uit uw doelgroep, los van uw eigen netwerk. Niet "vind je dit een goed idee" — dat zegt iedereen. Wel: "wanneer heb je dit probleem voor het laatst gehad, en wat deed je toen?" Als ze "nooit" of "ik gebruikte een Excel" antwoorden, weet u meer dan na een marktrapport. Schrijf vervolgens een probleem-stelling van maximaal drie zinnen: wie heeft het probleem, hoe vaak het voorkomt, en wat de huidige (gebrekkige) oplossing is.
- Probleem-stelling van maximaal drie zinnen, geschreven, niet alleen "in mijn hoofd".
- Acht tot tien gesprekken met mensen uit de doelgroep, met letterlijke quotes genoteerd.
- Inschatting hoe vaak het probleem voorkomt (dagelijks, wekelijks, maandelijks).
- Hypothese over wie ervoor zou betalen (of welke afdeling er budget voor heeft).
- Eerste schets van de "value proposition" in één zin.
Een idee valideren met je eigen team of investeerders. Dat is geen validatie, dat is bevestiging zoeken. Stem alleen met mensen die het probleem zelf hebben — en die u niet kent.
Fase 2 — Research
Validatie zegt dat er een probleem is. Research zegt wat er al bestaat, hoe het wordt opgelost, en waar de witte vlek zit. Twee soorten research die u altijd doet: concurrentie-analyse en technische haalbaarheidscheck.
Bij concurrentie-analyse zoekt u in de App Store en Google Play op de twee of drie kernwoorden van uw idee. Download de top vijf, gebruik ze, lees de reviews. Eén-sters-reviews zijn goud waard — dat is precies wat uw doelgroep mist. Maak een matrix: feature, concurrent A tot E, uw geplande aanpak. Waar bent u hetzelfde, waar anders, en is dat verschil betekenisvol genoeg om iemand te laten switchen?
Bij technische haalbaarheid kijkt u naar integraties (welke backend-systemen, welke externe API's), naar privacy- en compliance-eisen (AVG, sector-specifieke regelgeving voor medische of financiële data) en naar platform-bijzonderheden (push, achtergrondprocessen, offline-werking, biometrie). Niet om nu al oplossingen te kiezen — wel om verrassingen later te voorkomen.
- Concurrentie-matrix met minimaal vijf apps en hun belangrijkste features.
- Inzicht in wat de doelgroep mist in bestaande apps (op basis van reviews).
- Lijst van integraties met externe systemen (CRM, ERP, betaalprovider, kaart, identiteit).
- Compliance-eisen geïdentificeerd (AVG, sector-specifiek, App-Store-regels).
- Eerste indicatie van platform-eisen: offline ja/nee, push ja/nee, biometrie ja/nee.
"We zijn uniek, er is geen concurrentie." Dat klopt vrijwel nooit. Als u geen concurrenten vindt, kijkt u te smal — kijk dan naar de huidige oplossing van uw doelgroep (vaak een Excel, een Whatsapp-groep of een papieren proces). Dat is óók een concurrent.
Fase 3 — Strategie & doelen
Strategie is de brug tussen "we begrijpen het probleem" en "we gaan iets bouwen". U legt vast: wat is succes, hoe meten we het, en waarvoor is de app niet bedoeld. Die laatste is minstens zo belangrijk — een app die alles kan, is een app die niets goed kan.
Definieer drie tot maximaal vijf doelen met meetbare indicator. Niet "we willen meer engagement" — wel "60% van geregistreerde gebruikers in week twee nog actief". Niet "we willen tijd besparen" — wel "de gemiddelde doorlooptijd van het huidige proces halveren". Concreet maken dwingt focus af.
Hier kiest u ook het businessmodel: gratis met advertenties, eenmalig betaald, abonnement, in-app-purchases of B2B-licentie. Elk model heeft andere implicaties — een abonnementsmodel vraagt om Apple/Google in-app-billing en een goed account-systeem, een B2B-licentie vraagt om SSO en een admin-panel. Die keuzes maakt u nu, niet halverwege de bouw.
- Drie tot vijf doelen, elk met meetbare indicator.
- Expliciete "niet-doelen": wat gaat deze app uitdrukkelijk niet doen.
- Businessmodel-keuze met onderbouwing.
- Primaire en secundaire doelgroep beschreven (persona-niveau, geen demografie).
- Gedeelde definitie van "MVP" — wat is het minimum om de doelen te halen.
Doelen formuleren als "een mooie app maken". Mooi is geen doel — het is een randvoorwaarde. Doelen gaan over wat de app voor de gebruiker en voor uw organisatie moet veranderen.
Fase 4 — MoSCoW-scope
Hier komt de meest onderschatte fase van het hele traject. Iedereen wil alles in versie 1. En iedereen leert pijnlijk dat dat niet kan — bij voorkeur niet in week twaalf van de bouw. De MoSCoW-methode dwingt die keuzes vooraf af door elke gewenste feature in te delen in vier categorieën: Must have, Should have, Could have, Won't have (voor nu).
Must have is de keuren-of-kelderen-lijst: zonder deze features is de app niet bruikbaar voor het kerngebruiksgeval. Houd dit ruthless beperkt — vaak zes tot twaalf items voor een eerste versie. Should have is belangrijk maar uitstelbaar — als de bouw uitloopt, valt dit eerst af. Could have is leuk-als-er-tijd-over-is. Won't have is een expliciete keuze om iets niet nu te doen, met de afspraak dat het bespreekbaar is in een volgende versie.
De truc van MoSCoW zit in dat laatste lijstje. "Won't have" voorkomt dat hetzelfde feature elke twee weken opnieuw ter discussie staat. U heeft de keuze al gemaakt — en die staat zwart-op-wit.
Als uw Must-have-lijst langer is dan twaalf items, bouwt u geen MVP, u bouwt versie 1.0 van iets dat eigenlijk drie producten is. Splits.
- MoSCoW-lijst ingevuld en door alle stakeholders ondertekend.
- Must-have-lijst tussen zes en twaalf items.
- Won't-have-lijst expliciet (zodat herhaalde discussies voorkomen worden).
- Voor elke Must-have: één-zin user-story ("Als [type gebruiker] wil ik [actie] zodat [waarde]").
- Acceptatie-criteria per Must-have: hoe weten we dat het feature af is.
Geen MVP-discipline. "Het móét er allemaal in want anders snapt de gebruiker het niet." Bijna altijd onjuist. Een gebruiker snapt een app met één duidelijk doel veel beter dan een app met dertien half-uitgewerkte features. Vertrouw op de kracht van focus.
Fase 5 — Wireframes & UX
Wireframes zijn de plattegrond — schermen in lo-fi, zonder kleur en typografie, alleen over structuur, navigatie en informatie-hiërarchie. U begint met pen-op-papier of Figma in zwart-wit. Daarna een klikbaar prototype waarin een gebruiker door de happy-paths loopt.
Dat prototype is uw goedkoopste user-test. Laat het zien aan minimaal vijf doelgroep-gebruikers, geef ze een opdracht ("registreer en plaats een eerste order") en kijk waar ze vastlopen zonder dat u helpt. Drie van de vijf die hetzelfde misinterpreteren is geen toeval — dat is een ontwerpfout. UX gaat óók over de minder zichtbare zaken: foutboodschappen, lege staten, laad-toestanden, onboarding. Vaak vergeten, vaak hoofdoorzaak van slechte App-Store-reviews. Wireframe ook deze.
- Wireframes voor alle Must-have-schermen plus foutstaten en lege staten.
- Klikbaar prototype getest met minimaal vijf doelgroep-gebruikers.
- Bevindingen verwerkt (of bewust niet, met argumentatie).
- Navigatie-structuur vastgesteld (tab-bar, drawer, of stack).
- Onboarding-flow uitgewerkt — eerste keer openen tot eerste waarde-moment.
Te vroeg ontwerpen. Mensen willen het visuele design zien en slaan wireframes over. Resultaat: discussies over kleur in plaats van over structuur, en design-rondes die uit moeten omdat de architectuur niet klopt. Wireframes eerst, kleur later.
Fase 6 — Visueel design
Pas als de wireframes goed staan komt de visuele laag erop: kleuren, typografie, ikonografie, micro-interacties. Input is uw merkidentiteit, output is een design-systeem en hi-fi schermen voor alle Must-have-flows.
Ontwerp niet voor één apparaat. iOS en Android hebben subtiel andere conventies — een back-knop, een navigatie-stijl, een typografische schaal — die u kunt respecteren zonder twee aparte ontwerpen te maken. Ontwerp dark mode in elk geval voor de hoofdschermen — in 2026 een standaard-verwachting. De acceptatie-test is niet "vinden we het mooi" maar "scoort het op de doelen": een knop die de primaire actie weergeeft moet visueel dominant zijn — hoe mooi de rest ook is, hiërarchie staat voorop.
- Design-systeem (kleuren, typografie, knoppen, formulieren, kaarten) gedocumenteerd.
- Hi-fi schermen voor alle Must-have-flows.
- Designs getoetst op zowel iOS als Android-conventies.
- Toegankelijkheids-check: contrast-ratio's, raakdoelen minimaal 44pt, dynamische tekstgrootte.
- Designs in Figma overgedragen met inspect-rechten voor de developers.
Designs in PDF aanleveren in plaats van in Figma. Een PDF verbergt afmetingen, marges, en interactie-states — wat developers tot gokken dwingt en tot oneindige correctierondes leidt. Lever altijd Figma met inspect-rechten.
Fase 7 — Ontwikkeling (sprint-based)
De bouwfase werkt het beste in korte iteraties waarin een afgebakende set features wordt opgeleverd, getest en intern beoordeeld. Elke sprint eindigt met een werkende build die u zelf op uw telefoon kunt installeren via Testflight (iOS) of een interne Play-Store-track (Android). U ziet de app groeien en kunt bijsturen voordat er lang in een verkeerde richting gebouwd is.
De sprint-cadans heeft drie vaste momenten: sprint-planning (wat gaan we doen, met welke acceptatie-criteria), sprint-review (wat is af, demo van de werkende build), en retrospective (wat ging goed, wat kan beter). Bij planning en review zit u, retrospective is optioneel. Onderdeel van de bouw is ook wat niet zichtbaar is in de UI: backend-API's, databank, authenticatie, monitoring en de CI/CD-pipeline die builds met één druk-op-de-knop in Testflight zet. Vraag in sprint één een diagram van de architectuur — niet om mee te bouwen, wel om te weten waar de keuzes zitten.
Onze aanpak werkt met sprintbudget en doorlopende oplevering. Op de proces-pagina staat hoe een sprint bij ons eruitziet — van planning tot demo en bijsturing.
- Alle Must-have-tickets voor deze sprint hebben acceptatie-criteria gehaald.
- Werkende build geïnstalleerd op echte testtoestellen (geen alleen-simulator).
- Demo gehouden, opmerkingen verwerkt of geprioriteerd voor volgende sprint.
- Niets in "in-progress" staan blijven over sprint-grenzen heen.
- Documentatie van API-endpoints up-to-date.
Wekelijkse demo's overslaan "omdat er nog niets zichtbaars is". Als er na een sprint van twee weken niets demonstreerbaar is, is dat het signaal — niet de reden om geen demo te doen. Zonder zichtbare voortgang verliest u grip op de planning.
Fase 8 — Testen (functioneel, security, accessibility)
Testen is geen aparte fase aan het eind, het is een laag die door alle bouwsprints heen loopt. Toch is er vlak voor een release een testperiode waarin u alles bij elkaar tegen het licht houdt. Drie soorten tests, geen overslaan:
Functioneel testen
Werkt elk feature zoals beschreven in de acceptatie-criteria? Test niet alleen de happy path — test ook randgevallen: lege invoer, hele lange invoer, speciale tekens, traag of geen netwerk, offline naar online, achtergrond naar voorgrond. Een ervaren tester vindt in korte tijd dingen die de bouwer zelf nooit gezien zou hebben.
Security-tests
Minimaal een OWASP Mobile Top 10-check: insecure data storage, weak authenticatie, onveilige communicatie (geen TLS-pinning), code-injection. Voor apps met financiële of medische data is een externe pen-test in deze fase verstandig — niet vlak voor release, maar zodra er nog ruimte is om bevindingen op te lossen.
Accessibility-tests
Test met VoiceOver (iOS), TalkBack (Android), grote dynamische tekst en hoge-contrast-mode. Accessibility is geen nice-to-have — het is wetgeving (Europese Toegankelijkheidsakte), en het raakt een bredere groep gebruikers dan veel mensen denken. Apps die met VoiceOver volledig stuk zijn vallen in de App-Store-review steeds vaker op.
- Test-cases geschreven voor alle Must-have-features, inclusief edge cases.
- Testdata-set beschikbaar (realistische gebruikers, orders, producten, scenario's).
- Security-checklist (OWASP Mobile) doorgelopen, bevindingen opgelost.
- Accessibility-audit met VoiceOver/TalkBack, kritieke fouten opgelost.
- Crash-reporting actief (Sentry, Firebase Crashlytics) en getest.
- Analytics-events geïmplementeerd zodat u na launch metrics ziet.
Geen testdata. Een tester die elke keer zelf een gebruiker moet aanmaken om iets uit te proberen test minder. Lever een seed-script of een test-database met representatieve data — dat is werk dat zich vijftig keer terugbetaalt.
Fase 9 — App-store-publicatie
De technische bouw is af, nu komt de hindernisbaan: Apple App Store Review en Google Play Console. Reken op minimaal één afkeur-ronde van Apple — dat is geen falen, dat is hoe het werkt.
Voor Apple let u op: bezwaren tegen privacy-policy-teksten, de "Sign in with Apple"-verplichting als u andere social-logins biedt, de in-app-purchase-regels (digitale content móét via Apple's IAP, geen externe betaal-link), en de "minimum functionality"-regel — een app die niet meer doet dan een website verbergen wordt afgewezen. Lees de App Store Review Guidelines vóór de eerste submission, niet erna. Voor Google Play is het meestal soepeler, maar let op: data safety form (uitgebreide opgave wat de app verzamelt en waarom), target-API-versie-eisen, en de signing-key — die u éénmaal kwijtraakt en nooit meer terugkrijgt. Bewaar de keystore op meerdere veilige plekken.
- Developer-accounts opgericht op naam van uw organisatie (niet op een persoon).
- App Store Connect en Google Play Console ingericht, rollen verdeeld.
- Privacy-policy en algemene voorwaarden gepubliceerd op een vaste URL.
- App-iconen, screenshots, beschrijvingen, keywords voorbereid (per taal).
- Apple App Privacy + Google Data Safety formulieren ingevuld en consistent met de werkelijkheid.
- Backup van keystore op minimaal twee veilige plekken.
- Eerste submissie ingestuurd, afkeur-ronde verwerkt.
App-store-accounts op een persoon zetten. Die persoon vertrekt, het account is alleen via die persoon te bereiken, en uw app hangt op enterprise-niveau aan een privé-Apple-ID. Altijd op een organisation-account, met een dedicated mailbox.
Fase 10 — Beheer & iteratie
De app is live. Geen feest, geen einde — een begin. Een app die niet doorlopend wordt onderhouden raakt sneller onbruikbaar dan eigenaren denken: iOS en Android brengen jaarlijks grote updates uit (nieuwe API-eisen, nieuwe permission-modellen, deprecated frameworks) en niet meebewegen betekent dat uw app op een gegeven moment uit de stores valt.
Beheer kent drie lagen. Operationeel: monitoring van crash-rate, performance, server-uptime, kosten van cloud-resources, beveiligingsupdates van dependencies. Feature-iteratie: doorbouwen op basis van analytics en gebruikersfeedback — niet meer raden, u heeft nu data. Platform-meebewegen: jaarlijkse iOS/Android-major-versies, nieuwe schermafmetingen, nieuwe accessibility-eisen. Doorlopend werken op basis van een vast sprintbudget per maand werkt voor de meeste partijen het beste — u kunt aanpassen, en betaalt geen vast bedrag voor een feature-pakket dat niet bestaat. Wat u niet wilt is een "klaar is klaar"-contract zonder beheer-component — dat is hoe apps verloederen.
Reserveer een doorlopende capaciteit voor beheer, ook als er "niets ontwikkeld" wordt. Zonder dat ritme is het de eerste post die wordt geschrapt — en zes maanden later kost het driedubbel om weer aan te haken bij de platforms.
- Monitoring-dashboard met crash-rate, latency, kostenontwikkeling.
- Roadmap voor de eerstvolgende twee tot drie kwartalen, geprioriteerd.
- SLA of werkafspraak met de bouwer over reactietijden bij incidenten.
- Eigenaarschap van de codebase, accounts, en sleutels formeel vastgelegd.
- Vaste cadans (maandelijks of kwartaal) voor gezamenlijke evaluatie van metrics en backlog.
Geen post-launch plan. "We zien wel hoe het loopt." Dat ziet er na drie maanden zo uit: kleine bugs zijn niet opgelost, de eerste OS-update breekt iets, de bouwer is alweer aan een ander project, en u staat alleen. Plan de eerste zes maanden beheer vóór de release.
Wat u als opdrachtgever in elke fase doet
Een app laten maken is geen aanbesteding waarbij u een specificatie inlevert en later een product ontvangt. De rol van opdrachtgever is actief — en die actieve rol bepaalt of het traject lukt. Per fase ziet het er als volgt uit:
| Fase | Wat u doet |
|---|---|
| 1. Validatie | Zelf de doelgroep-gesprekken voeren. Niemand anders kent uw idee zo goed. |
| 2. Research | Concurrentie meebeleven, bij voorkeur de top-vijf zelf installeren en gebruiken. |
| 3. Strategie | Doelen vaststellen, "niet-doelen" durven uitspreken. |
| 4. Scope | Knopen doorhakken bij MoSCoW-discussies. U bent de tiebreaker. |
| 5. UX | Bij de user-tests aanwezig zijn, niet alleen het rapport lezen. |
| 6. Design | Toetsen op merk en doelen, niet alleen op smaak. |
| 7. Bouw | Elke sprint-review bijwonen, beslissingen niet uitstellen. |
| 8. Testen | Zelf meetesten, niet alles aan de tester overlaten. |
| 9. Publicatie | Beheer van developer-accounts, content voor stores. |
| 10. Beheer | Maandelijkse evaluatie van metrics, prioriteiten herijken. |
Zonder actieve opdrachtgever wordt elk app-traject defensief: de bouwer maakt veilige keuzes om geen discussie te krijgen — en veilige keuzes zijn zelden de beste. Aanwezigheid en duidelijkheid tillen een traject van degelijk naar goed.
Veelgestelde vragen
Kan ik fases overslaan om tempo te maken?
Wat we in praktijk zien is dat overgeslagen fases later met rente terugkomen — een overgeslagen validatie-fase betaalt zich uit in een app die niemand opent, een overgeslagen scope-fase in een backlog die nooit leegloopt. Tempo zit niet in fases overslaan; tempo zit in iedere fase scherp en kort houden.
Wat kost een app laten maken eigenlijk?
Dat hangt af van scope, platform-keuze, integraties en businessmodel. Zie de gids over app-laten-maken-kosten voor welke knoppen de prijs sturen.
Hebben we iemand intern nodig?
Minstens één product-owner of vergelijkbare rol. Geen technisch profiel verplicht — wel iemand die beslissingen kan nemen zonder steeds terug naar een grotere groep. Apps die zonder zo'n persoon worden gebouwd lopen vast in besluitvorming, niet in techniek.
Hoe weet ik of mijn idee een interne bedrijfsapp wordt of een publieke product-app?
Het verschil zit in distributie, beheer en gebruikersbeleving. Interne bedrijfsapps kennen eigen valkuilen — voor wie die route overweegt, lees de gids over interne bedrijfsapps met tien valkuilen.
Past dit ook bij no-code of low-code platforms?
De eerste vijf fases zijn identiek — validatie, research, strategie, scope en UX zijn platform-onafhankelijk. Vanaf fase zes verandert het werk in detail, maar de stappenstructuur blijft. Sla validatie of scope nooit over omdat u "snel iets in elkaar zet" — de duurste no-code-apps zijn die zonder MoSCoW.
Bij wie kan ik aankloppen voor een second opinion?
Stuur een mail naar fabian.vandijk@appfront.nl met waar u staat. Een kennismaking is een half uur, geen offerte-druk, gewoon een gesprek over waar het knelt. Voor onze aanpak van app-ontwikkeling staat op de dienstpagina hoe wij samenwerken.