Het Flutter-ontwikkelproces, stap voor stap

Kort samengevat. Het Flutter-ontwikkelproces loopt in zeven fasen: verkenning en afbakening, UX/UI-ontwerp, architectuur en fundamenten, iteratief bouwen, testen en kwaliteit, uitbrengen, en onderhoud na de lancering. Wat ze verbindt is dat het terugkoppellussen zijn, geen waterval — het ontwerp begint voordat de verkenning klaar is, testen loopt naast de bouw in plaats van erna, en elke twee weken krijg je iets installeerbaars op je telefoon in plaats van een statusrapport. De ene regel waar we niet van afwijken: de invarianten komen vóór de functiecode. Het statemodel, het thema, de foutentaxonomie, de CI-pijplijn en de teststrategie worden in week één bepaald, want elk scherm dat daarna wordt gebouwd volgt ze of vecht ertegen. Een gebruikelijke bouw is 2 tot 3 maanden voor een MVP en 3 tot 5 maanden voor een volledig product, en de lancering is het midden van het proces, niet het einde.

De stappen van Flutter-appontwikkeling in één oogopslag

Zeven fasen, in de volgorde waarin ze beginnen. Dit is de hele Flutter-ontwikkelcyclus op één scherm.

Fase	Wat er gebeurt	Belangrijkste oplevering	Wie erbij zit	Gebruikelijke duur
1. Verkenning en afbakening	Het idee wordt een concrete, geordende backlog; de schraplijst wordt afgesproken	Afgebakende backlog, offerte met vaste scope, planning	Oprichter of productleider, technisch leider, ontwerper	3 dagen – 2 weken
2. UX/UI-ontwerp	Eerst het designsysteem, daarna stromen en schermen daartegen	Designsysteem plus klikbaar prototype	Ontwerper, productleider, technisch leider	2–4 weken (overlapt de bouw)
3. Architectuur en fundamenten	Statemodel, mapindeling, foutentaxonomie, CI/CD, teststrategie	Draaiend appskelet, groene pijplijn, besluitregistraties	Technisch leider, backendengineer	1–2 weken
4. Iteratief bouwen	Verticale functieplakken, elke sprint demonstreerbaar	Elke 1–2 weken een installeerbare build	Engineers, ontwerper, productleider	4–16 weken
5. Testen en kwaliteit	Widget-, golden-, integratie- en toesteltesten	Testsuite in CI plus een hardingsronde	Engineers, testers, testers bij de klant	Doorlopend plus 1–2 weken harden
6. Uitbrengen	Winkelmateriaal, indienen, beoordeling, gefaseerde uitrol	Live app in de App Store en Google Play	Technisch leider, productleider, accounts van de klant	1–2 weken
7. Na de lancering	Monitoring, crashes afhandelen, itereren op echt gebruik	Maandelijkse releasecadans, crashvrij percentage	Engineers, productleider	Doorlopend

Die duren zijn bandbreedtes, en ze overlappen — de kalender is korter dan de som van de rijen. Waar de weken in een echt project werkelijk heen gaan staat in het bijbehorende stuk: hoe lang het duurt om een Flutter-app te bouwen. Wat elke fase kost staat in Wat een Flutter-app kost in 2026.

Structureel is dit hetzelfde proces voor mobiele appontwikkeling dat elk bekwaam team draait — de fasen zijn geen uitvinding van Flutter. Wat Flutter verandert is de economie erbinnen: één codebase om voor te ontwerpen, één om te testen, één om uit te brengen, en een interfacelaag die in code leeft in plaats van in een stylesheet. Dat laatste detail is waarom de ontwerp- en architectuurfasen hier zwaarder wegen dan elders.

1. Verkenning en afbakening

Verkenning is de fase waarin een idee een concrete, geordende lijst dingen wordt om te bouwen. Het is geen workshop met plakbriefjes. Het is een technisch leider en een ontwerper die de app doorvragen tot elk scherm een reden heeft om te bestaan.

Er komen drie dingen uit:

Een backlog, geordend. Niet "gebruikersbeheer" — "inloggen met Apple, inloggen met e-mail, wachtwoordherstel, account verwijderen." Vage regels zijn waar ramingen sterven.
Een schraplijst. De functies die niet in versie één zitten, opgeschreven en afgesproken. Het waardevolste document in het proces, en degene waar klanten zich het hardst tegen verzetten.
Een offerte met vaste scope en een planning, afgeleid uit de backlog en niet uit een onderbuikgevoel over "een app als deze".

Hier worden budgetten en planningen werkelijk gezet, en daarom is een gehaaste verkenning de duurste manier om een week te besparen. Beschrijf je "een simpele trainingstracker" en geven wij een backlog van 40 schermen terug, dan is dat gat geen opvulling — onboarding, authenticatie, instellingen, account verwijderen, betalingen, pushmeldingen en offline werken zaten altijd al in de app die je beschreef. De kostenuitsplitsing behandelt hoe scope tot een bedrag optelt.

Waar het breekt: verkenning met iemand die niet kan beslissen. Gaat elk antwoord terug naar een commissie, dan rekt de verkenning van één week naar vier en staat de raming op drijfzand.

2. UX/UI-ontwerp

UX/UI-ontwerp is de fase waarin de visuele en interactietaal van de app wordt vastgelegd. Het begint bij het systeem, niet bij de schermen.

De eerste oplevering is een designsysteem: een palet met lichte en donkere varianten, een typografische ladder, een ruimteschaal, componentstaten (standaard, ingedrukt, uitgeschakeld, ladend, fout), en de interactiewoordenschat — hoe deze app laden toont, een lege lijst toont, een onomkeerbare handeling bevestigt. Schermen worden daarna tegen dat systeem ontworpen.

Die volgorde is geen esthetische voorkeur; het is bouwsnelheid. Een Flutter-app rendert elke pixel uit Dart-code, en een volwassen designsysteem valt vrijwel één op één op ThemeData af te beelden — één keer aangesloten, en elk later scherm wordt samengesteld uit componenten die al bestaan. Zonder krijg je wat we beschrijven in hoe AI-agents worstelen met Flutter: veertig schermen die elk werken en samen geen app vormen, kleuren die op elke aanroepplek hard staan, en een merkwijziging die een diff van enkele honderden bestanden kost.

We ontwerpen ook voor de beperkingen die Flutter-lay-outs later breken — lange teksten in de tweede taal, 200% tekstgrootte, kleine telefoons op 320pt. Die in Figma vangen kost minuten; ze bij het testen vangen kost een herontwerp. Wat je uit de fase krijgt is een designsysteem plus een klikbaar prototype, voordat er één regel functiecode bestaat.

Waar het breekt: ontwerpen per beoordelingsronde. Drie rondes "kunnen we nog één optie zien" op het beginscherm vertraagt elke fase erachter, want engineers kunnen niet tegen een bewegend doel bouwen.

3. Architectuur en fundamenten

Architectuur is de fase waarin de besluiten vallen waar elk later scherm van afhangt — voordat er een scherm bestaat. Praktisch betekent dat dat we een of twee weken een app bouwen die niets doet.

Die veertien dagen bepalen de volgende zes maanden. Wat er wordt beslecht:

Statebeheer. Eén keuze, overal toegepast. Sealed stateklassen, zodat onmogelijke combinaties — tegelijk ladend en fout — niet weer te geven zijn in plaats van slechts onwaarschijnlijk.
Mapindeling en modulegrenzen. Waar een functie leeft, wat hij mag importeren.
Een foutentaxonomie. Benoemde faalwijzen — netwerk, verlopen authenticatie, validatie, geweigerde betaling, conflict — in plaats van één Er ging iets mis dat elke bug onreproduceerbaar maakt.
CI/CD. Pijplijn groen op dag één: flutter analyze met lints tot fouten verheven, flutter test, een buildartefact per commit, Fastlane aangesloten op TestFlight en het interne kanaal van Play.
Teststrategie. Welke lagen widgettests krijgen, welke schermen goldens krijgen, wat het framebudget is.

Wij noemen dat de invarianten, en ze komen eerst omdat ze niet goedkoop achteraf zijn aan te brengen. "Volg het bestaande patroon" is een goedkope instructie om aan een mens of een agent te geven — maar alleen zodra er een patroon is om naar te wijzen. In een repo zonder verzint iedereen zijn eigen, en het resultaat is de opgraving waarvoor we twee jaar later betaald worden om te beoordelen. De fase eindigt met een draaiend skelet, een groene pijplijn, en korte besluitregistraties voor de keuzes die een toekomstige engineer anders opnieuw ter discussie stelt.

4. Iteratief bouwen

Iteratief bouwen is de fase waarin functies in kleine, demonstreerbare stappen worden gebouwd en opgeleverd in plaats van in één klomp aan het eind. De Flutter-werkstroom loopt hier in verticale functieplakken: één functie van begin tot eind gebouwd — interface, state, API-koppeling, foutafhandeling, tests — in plaats van "alle schermen" gevolgd door "alle leidingen". Een plak die je op een telefoon kunt openen vertelt je iets waars. Een map met niet-aangesloten schermen niet.

De cadans is elke een tot twee weken een demonstreerbare stap, op jouw toestel via TestFlight of het interne kanaal van Play. Geen schermafbeelding, geen video — de app, op je telefoon, die je aan een collega kunt geven.

Code review gaat over besluiten, niet over regels. Is dit hetzelfde statemodel als de rest van de app? Is het vanuit het thema vormgegeven? Wordt deze waarde één keer afgeleid, of voor de derde keer? Overleeft deze tekst het Russisch? Agents schrijven een groot deel van de code en onze engineers nemen die besluiten, en zo bouwen wij — regel voor regel gegenereerde code beoordelen schaalt niet; op besluitniveau beoordelen wel.

Ontwerp en testen lopen ondertussen door, en backendwerk ook — en daarom wordt een systeem als de realtime marktdatalaag achter ExtraETF gebouwd en belast getest terwijl de Flutter-client nog schermen tegen een namaakendpoint samenstelt.

Waar het breekt: stille sprints. Gaan er twee weken voorbij zonder dat je een build opent, dan is de lus gebroken en hoor je een maand te laat over het misverstand.

5. Testen en kwaliteit

Testen is de laag die van de eerste functieplak tot de laatste doorloopt, geen fase die er aan het eind op wordt geschroefd — geautomatiseerde controles in CI bij elke commit, plus een hardingsronde vóór de release.

Wat er bij elke commit in CI draait:

Widgettests voor gedrag: de knop wordt uitgeschakeld tijdens het versturen, de fout verdwijnt bij opnieuw typen, de lijst pagineert op de juiste plek.
Goldentests voor het uiterlijk — het testtype met de grootste hefboom in Flutter, want een golden maakt van "brak dit herontwerp de lege staat op 320pt in donkere modus bij 200% tekstgrootte?" een controle die in seconden draait in plaats van een vraag die niemand stelt.
Integratietests voor de stromen die geld kosten als ze breken: aanmelden, afrekenen, betalen.
Een regressietest voor elke opgeloste bug, zodat hij niet terug kan komen.

Wat een machine niet kan, doet een mens op echte hardware: de app op 200% tekstgrootte, in donkere modus, in beide talen, op een kleine oude Android-telefoon, met het netwerk geknepen en daarna midden in een verzoek afgesloten. Tien minuten daarvan vindt een hele categorie defecten die geen statische controle ooit meldt.

En we houden een framebudget aan — 16,6 ms bij 60 fps, gecontroleerd op profielbuilds. Een lijst die hapert nadat iemand een schaduw en een Opacity in de itembuilder heeft gezet, is een regressie die geen unittest vangt en elke gebruiker voelt.

6. Uitbrengen

Uitbrengen is de fase waarin de app door indiening, beoordeling en uitrol gaat. Het is 1 tot 2 weken werk dat de meeste planningen voor een middag aanzien.

Winkelmateriaal en metadata — schermafbeeldingen in elk vereist formaat, beschrijvingen, trefwoorden, privacylabels, verklaringen over gegevensveiligheid. Account verwijderen moet in de app bestaan; beide winkels handhaven dat.

De realiteit van de beoordeling. De beoordeling van Apple duurt doorgaans 24 tot 48 uur, maar doorgaans is geen garantie, en de afwijscategorieën zijn voorspelbaar: ontbrekende accountverwijdering, een inlogmuur zonder demogegevens, een onvolledige privacyverklaring, betalingen die om de in-app-aankoop heen lopen. Voor wie meerdere merkapps uitbrengt is richtlijn 4.2.6 een vak apart — we behandelden wat werkelijk door de beoordeling komt op vlootschaal. De beoordeling van Google is meestal sneller, maar een nieuw ontwikkelaarsaccount kan dagen in verlengde beoordeling blijven hangen.

Gefaseerde uitrol. We leveren aan 10% op Google Play en kijken naar het crashvrije percentage voordat we verbreden; gefaseerd uitbrengen in de App Store doet hetzelfde. Een slechte build die je bij 10% betrapt is een slechte middag. Dezelfde build bij 100% is een slechte week.

Automatisering. Fastlane bouwt, ondertekent en uploadt naar beide winkels — inclusief opstellingen met meerdere uitgevers waarbij elk merk onder een eigen account uitkomt. Met de hand uitbrengen is waar om 23 uur een versienummer verkeerd wordt ingetypt.

7. Na de lancering en onderhoud

Onderhoud na de lancering is de fase waarin de app echte gebruikers ontmoet en blijft veranderen. De lancering is het begin ervan, niet het einde van het project.

Echt gebruik legt meteen bloot wat geen test kon: de Android-schil van een fabrikant die pushmeldingen breekt, de OS-update die een API uitfaseert, de crash op een toestel dat je niet bezat. Dus gaat het proces door:

Monitoring — crashrapportage, prestatiesporen en analyse op de stromen die ertoe doen, de eerste 48 uur elk uur bekeken en daarna wekelijks.
Iteratie — de backlog die je bij de verkenning schrapte, opnieuw geprioriteerd tegen wat mensen werkelijk doen.
Onderhoud — jaarlijkse OS-releases, SDK-updates, wijzigingen in winkelbeleid, certificaten en API-sleutels wisselen. Flutter en zijn plug-ins bewegen; een app die een jaar onaangeraakt blijft is niet stabiel, hij is oudbakken.

Begroot voor het product, niet voor het project. Een app die uitkomt en daarna niets meer krijgt, is langzaam onderweg terug naar een herbouw.

Hoe we het op koers houden

Processen falen niet dramatisch. Ze lopen een paar dagen tegelijk uit. Vier dingen voorkomen het meeste ervan, en elk heeft een bekende faalwijze.

Strakke scope, opgeschreven. De schraplijst uit de verkenning is een contract met de planning; nieuwe ideeën gaan op de v2-lijst en dat zeggen we hardop. Breekt wanneer niemand de lijst verdedigt — elke "kleine toevoeging" is werkelijk klein, en de twintigste is een maand.

Een besluitvaardige cadans met de opdrachtgever. Eén persoon die een scherm kan goedkeuren op de dag dat hij het ziet, een wekelijks gesprek, een build om te installeren. Breekt wanneer besluiten via een commissie lopen. Bij een bouw van zes weken is één week besluitvertraging al 20% overschrijding voordat een engineer iets fout heeft gedaan.

Invarianten vooraf gezet. De reden dat onze derde maand ongeveer kost wat onze eerste kostte. Breekt wanneer een deadline iedereen verleidt week één over te slaan en met schermen te beginnen.

Korte terugkoppellussen. Installeerbare builds elke een tot twee weken, testen in CI, een demo die je ook echt opent. Breekt wanneer de klant stil valt — de lus werkt alleen als er iemand aan de andere kant zit.

En de eerlijke: onze ramingen zitten in één richting fout. Koppelingen zijn waar ze het meest missen. Elke SDK van een derde partij lijkt in het voorstel een middag en wordt een debugsessie van twee weken over randgevallen op Android 10. We bouwen daar speling voor in in plaats van het weg te wensen, en gaat een fase overlopen, dan hoor je dat die week en niet op de deadline.

Veelgestelde vragen

Er zijn zeven stappen: verkenning en afbakening, UX/UI-ontwerp, architectuur en fundamenten, iteratief bouwen, testen en kwaliteit, uitbrengen, en onderhoud na de lancering. De verkenning maakt van het idee een geordende backlog en een vaste scope, het ontwerp levert een designsysteem en een prototype op, en de architectuur legt het statemodel, de foutafhandeling, de CI-pijplijn en de teststrategie vast voordat er functiecode wordt geschreven. Daarna bouwt de ontwikkeling functies in verticale plakken met testen dat ernaast loopt in plaats van erna, gevolgd door uitbrengen in de winkels en doorlopend onderhoud.

Het werkt als een set overlappende terugkoppellussen in plaats van een lineaire waterval. Het ontwerp begint voordat de verkenning klaar is, de technische fundamenten worden gelegd terwijl de laatste schermen worden ontworpen, en testen loopt doorlopend in continue integratie in plaats van als fase aan het eind. De klant ziet elke een tot twee weken een installeerbare build, en dat is de lus die misverstanden vangt terwijl ze nog goedkoop te herstellen zijn. Een gebruikelijke bouw is twee tot drie maanden voor een MVP en drie tot vijf maanden voor een volledig product.

De verkenning komt eerst: het idee omzetten in een concrete, geordende backlog met een expliciete lijst van wat niet in versie één zit. Budgetten en planningen worden hier werkelijk gezet en niet later, want alles daarna is uitvoering tegen deze besluiten. Aan de technische kant is het eerste wat gebouwd wordt geen functie maar het fundament — het statemodel, de mapindeling, de foutentaxonomie, de CI-pijplijn en de teststrategie — omdat die niet goedkoop achteraf zijn aan te brengen zodra er veertig schermen bestaan.

Testen loopt doorlopend, niet als slotfase. Widgettests dekken gedrag, goldentests vangen visuele regressies door gerenderde schermen met referentiebeelden te vergelijken, en integratietests dekken de stromen die geld kosten als ze breken. Daarbovenop testen engineers op echte toestellen bij 200 procent tekstgrootte, in donkere modus, in elke ondersteunde taal, en op een geknepen of weggevallen netwerk. Frametijden worden op profielbuilds tegen een budget van 16,6 ms gelegd, want haperen is een regressie die geen unittest vangt en elke gebruiker voelt.

De verkenning kost drie dagen tot twee weken, het ontwerp twee tot vier weken, en architectuur en fundamenten een tot twee weken. Iteratief bouwen loopt vier tot zestien weken afhankelijk van de scope, met testen doorlopend plus een hardingsronde van een tot twee weken. Uitbrengen kost een tot twee weken inclusief winkelmateriaal, beoordeling en gefaseerde uitrol. De fasen overlappen sterk, dus de kalender is korter dan de som van die bandbreedtes — doorgaans twee tot drie maanden voor een MVP en drie tot vijf voor een volledig product.

De lancering is het begin van het product, niet het einde van het project. De eerste 48 uur gaan op aan crashrapporten, prestatiesporen en het percentage van de gefaseerde uitrol bekijken voordat je verbreedt. Daarna wordt het werk itereren op echte gebruiksdata plus onderhoud: jaarlijkse releases van iOS en Android, updates van Flutter en plug-ins, wijzigingen in winkelbeleid, en certificaten en API-sleutels wisselen. Een app die uitkomt en daarna niets meer krijgt is niet stabiel, hij gaat stilletjes richting een herbouw.

Het wordt gebruikt als korte terugkoppellussen en niet als ceremonieel raamwerk. Werk wordt gebouwd in verticale functieplakken die van het scherm tot de backend reiken, zodat elke stap iets is dat je kunt installeren en gebruiken en geen map met niet-aangesloten schermen. Sprints duren een tot twee weken en elke sprint eindigt met een build op het toestel van de klant via TestFlight of het interne kanaal van Play. Wat bewust niet agile blijft is de architectuur: het statemodel, het thema, de foutentaxonomie en de teststrategie worden vooraf gezet, want daarop itereren wanneer er veertig schermen bestaan is een herbouw en geen sprint.

Baken je bouw met ons af

Zo worden Flutter-apps gebouwd wanneer iemand het proces werkelijk draait. Beoordeel je bureaus, dan is het proces het product — schermafbeeldingen kan iedereen laten zien. Wat bepaalt of je app op tijd uitkomt is of er een echte machine achter zit: een schraplijst die iemand verdedigt, invarianten die in week één worden gezet, elke veertien dagen een build op je telefoon, en tests die draaien voordat een mens kijkt.

Plan een verkennend gesprek en we halen je idee door stap één: neem contact op. Je krijgt een geordende backlog, een schraplijst, en een offerte met vaste scope — geen bandbreedte om je in te verstoppen.
Bekijk het aanbod — team, stack en tariefniveaus op de pagina Flutter-appontwikkeling.
Heb je al een bouw? Draaide iemand anders dit proces slecht, dan vertelt een audit van AI-code je wat het kost om het ter plekke te herstellen — vrijwel altijd minder dan de herbouw die je wordt aangeboden.

Vertel ons wat je bouwt en waar je vastzit, en we zeggen welke fasen makkelijk worden en welke pijn gaan doen.

Dima is lead Flutter-developer bij Nerdy Production, een Flutter-eerst bureau dat apps van verkenning tot de App Store brengt in fintech, retail en AI-producten.

Het Flutter-ontwikkelproces: hoe we een app van idee naar App Store brengen