Kort samengevat. Een Flutter-:term{slug="mvp"} kost doorgaans 6 tot 12 weken van aftrap tot een live winkelvermelding. Een gangbare zakelijke app kost 3 tot 6 maanden. Een complexe of gereguleerde app — fintech, zorg, alles wat een accountant gaat lezen — kost 6 tot 12 maanden of meer. De variabele die die getallen het sterkst verschuift is niet hoe snel iemand code schrijft: het is de scope, en hoe snel er aan de kant van de klant besluiten vallen. De fasen overlappen ook, dus de kalender is altijd korter dan de som van de fasen — en daarom zijn "hoe lang" en "hoeveel werk" twee verschillende vragen.
Elk bureau beantwoordt dit met "het hangt ervan af". Dat klopt — maar daar plan je geen lancering op. Dit zijn de getallen die wij noemen, wat erin zit, en waardoor ze uitlopen.
Hoe lang duurt een Flutter-app, naar complexiteit?
Drie niveaus dekken vrijwel alles waar we om gevraagd worden. De duur loopt van aftrap tot winkelvermelding, uitgaande van een getekende scope en redelijke toegang tot wie de besluiten neemt.
| Niveau | Gebruikelijke duur | Voorbeeldfunctieset | Team | Grootste bepaler van de planning |
|---|---|---|---|---|
| MVP — het idee toetsen | 6–12 weken | 5–8 kernfuncties, iOS en Android, Firebase of een lichte REST-backend, interface uit een componentbibliotheek, basisanalyse | 1–2 Flutter-engineers, ontwerper in deeltijd, technisch leider | Discipline op de scope. Elke "kleine toevoeging" is een week. |
| Gangbare zakelijke app | 3–6 maanden | 15–20 functies, eigen designsysteem, eigen backend, beheerdashboard, gesegmenteerde pushmeldingen, offline werken, betalingen | 2–3 Flutter-engineers, backendengineer, ontwerper, tester | Koppelingen en gereedheid van de backend — meestal niet de app |
| Complex of gereguleerd | 6–12+ maanden | Compliancewerk (HIPAA, PCI-DSS, SOC 2), toegang op rollen, realtime data, ERP- en CRM-koppelingen, machine learning op het toestel | Volledig team plus DevOps en een projectleider | Afhankelijkheden die je niet in de hand hebt: accountants, banken, leveranciers |
Drie tot vijf maanden is de gebruikelijke bouw van een zakelijke app; de zesde maand duikt op wanneer koppelingen of compliance laat binnenkomen, wat vaak gebeurt. Deze niveaus komen overeen met de prijsniveaus in Wat een Flutter-app kost in 2026 — ruwweg € 12-24K voor het MVP-niveau, € 24-48K voor het zakelijke niveau. Duur en budget bewegen samen: je koopt een team voor een aantal weken.
Waar gaan de weken werkelijk heen?
De derde kolom is de belangrijke: deze fasen lopen niet na elkaar.
| Fase | Gebruikelijke duur | Overlapt met |
|---|---|---|
| Verkenning en afbakening | 3 dagen – 2 weken | Poort naar alles; niets echts begint eerder |
| UX/UI-ontwerp | 2–4 weken | Begint voordat de verkenning sluit; de staart loopt de bouw in |
| Architectuur en fundamenten | 1–2 weken | Ontwerp |
| Kernbouw | 4–16 weken | Staart van het ontwerp, testen, backendwerk |
| Koppelingen | 1–2 weken per grote koppeling | Kernbouw |
| Testen en kwaliteit | Doorlopend, plus een hardingsronde van 1–2 weken | Kernbouw |
| Indienen en beoordeling in de winkels | 1–2 weken (de beoordeling zelf meestal 24–48 uur) | Loopt als laatste; materiaal eerder voorbereid |
Tel die rijen naïef op en je komt op acht maanden voor een bouw die in vier uitkomt. De overlap is het verschil: het ontwerp maakt schermen af terwijl engineers de al goedgekeurde bouwen, testen loopt binnen elke sprint, en de backend wordt tegen een namaakclient belast getest. Wat er binnen elke fase gebeurt, staat in het bijbehorende stuk over het Flutter-ontwikkelproces — dit stuk is het hoe lang, dat het hoe.
Hoe lang duurt een MVP tegenover een volledig product?
Een MVP kost 6 tot 12 weken omdat een MVP een vraag is en geen product: 5 tot 8 functies, interface uit een componentbibliotheek, een backend die je niet vanaf nul hebt geschreven, en een schraplijst waar je je ook aan houdt.
De ondergrens van 6 weken is echt maar voorwaardelijk. Het vraagt een scope die op één pagina past, één persoon die zonder commissie een besluit kan goedkeuren, en geen nieuw technisch risico — geen videopijplijn, geen machine learning op het toestel, geen betaalinfrastructuur in een nieuw rechtsgebied. Een Telegram-bot met een bestaand gebruikersbestand omzetten naar een native app was zes weken, omdat de bot het product al had bevestigd en de scope vaststond.
Tien tot twaalf weken komt vaker voor, en die extra maand is bijna nooit "de code was lastiger" — het is een betaalstroom die in week vier opdook, een niet-begrote ontwerpronde, of twee weken wachten op API-toegang.
Een volledig product kost 3 tot 6 maanden om een reden die los staat van het aantal functies: het is gebouwd om echt gebruik te overleven — eigen designsysteem, echte bedrijfslogica, offline gedrag, benoemde foutschermen, tests in CI, een beheerpaneel voor wie de ondersteuning draait. Dat is het werk dat een app waarmee je kunt groeien scheidt van een app die je over anderhalf jaar herschrijft.
Wat bepaalt de planning werkelijk?
Zes dingen, ruwweg op volgorde van hoeveel schade ze aanrichten.
1. Scope. Met afstand. "Een simpele app" wordt 40 schermen zodra onboarding, authenticatie, instellingen, account verwijderen, betalingen, pushmeldingen en offline werken zijn meegeteld — die allemaal altijd al in de app zaten die je beschreef. Twee extra functies voegen geen twee weken programmeren toe; ze voegen programmeren, ontwerp, testen en een verse set randgevallen toe.
2. Gereedheid van de backend. Bestaat de API, is hij gedocumenteerd en stabiel, dan draait het Flutter-team op volle snelheid. Schrijft een ander team hem parallel, dan is jouw planning nu hun planning.
3. Koppelingen. Elke betekenisvolle — betalingen, kaarten, chat, video, biometrie, een CRM — kost een tot twee weken. De SDK kost een middag; de randgevallen kosten de veertien dagen.
4. Volwassenheid van het ontwerp. Aankomen met een designsysteem bespaart twee tot drie weken, omdat engineers schermen samenstellen uit componenten die bestaan. Helemaal geen ontwerp is niet sneller — het verplaatst het werk naar de bouw, waar het meer kost.
5. Beoordeling in de winkel. Een tot twee weken voor de indieningsfase, waarvan het meeste jouw werk is en niet dat van Apple. Meer hieronder.
6. Besluitvertraging — meestal jij. Een bouw kent tientallen open vragen, elk wachtend op iemand. Tien daarvan in vier dagen beantwoord in plaats van in één voegt zes weken toe aan een project waarin niemand een trage regel schreef. In een gezond project is de klant het meest voorkomende knelpunt — en het goedkoopste om te verhelpen.
Bouwt Flutter sneller dan native?
Ja — maar wees precies over wat er bespaard wordt, want hier claimen bureaus te veel.
Flutter verlaagt de bouwinspanning met ruwweg 30 tot 40% ten opzichte van twee native apps uitbrengen, en het gat groeit over de levensduur van het product omdat elke latere functie één keer wordt geschreven in plaats van twee keer. Waar dat getal vandaan komt splitsten we uit in Flutter tegenover native in 2026.
Wat het niet doet is de kalender halveren. De verkenning wordt niet korter omdat je Flutter koos, ontwerp gebeurt hoe dan ook één keer, testen vraagt nog steeds echte toestellen op beide platforms, en de backend maalt niet om waarin de client is geschreven. Een native bouw van zes maanden op twee platforms wordt ruwweg een Flutter-bouw van vier maanden — geen drie — met één team in plaats van twee en één codebase om daarna te onderhouden.
Flutter is hoe je twee platforms voor bijna de prijs van één krijgt. Het is niet hoe je een app van zes maanden in zes weken krijgt.
Hoeveel tijd kost de beoordeling in de App Store en Play?
Begroot één tot twee weken voor de hele indieningsfase en je zit zelden mis. De beoordeling zelf is het kleine deel.
De beoordeling van Apple duurt doorgaans 24 tot 48 uur na het indienen. Doorgaans is geen garantie, en de afwijsredenen zijn voorspelbaar genoeg om omheen te ontwerpen: ontbrekende accountverwijdering, een inlogmuur zonder demogegevens, een onvolledige privacyverklaring, betalingen die om de in-app-aankoop heen lopen. De beoordeling van Google is meestal sneller, al kan een gloednieuw ontwikkelaarsaccount dagen in verlengde beoordeling blijven hangen.
De tijd die werkelijk zoekraakt is de afwijsronde — een heen en weer van 24 tot 72 uur, en een eerste indiening die er een krijgt is normaal. Reken op één en je vangt hem op; reken op geen en hij landt op je lanceerdatum.
Twee gevallen duren langer: gereguleerde gegevens roepen extra vragen op, en meerdere merkapps uit één codebase uitbrengen maakt richtlijn 4.2.6 van Apple een vak apart — dezelfde schermen met een nieuw logo worden als duplicaten afgewezen. We schreven op wat op vlootschaal werkelijk door de beoordeling komt; daar vooraf voor ontwerpen is het verschil tussen een indiening van een week en een maand bezwaarschriften.
Waar loopt de planning uit?
Vier faalwijzen verklaren vrijwel elke overschrijding die we hebben gezien.
Uitdijende scope die als kleine verzoeken binnenkomt. Geen enkele "kunnen we ook nog…" is onredelijk. Zes ervan zijn een maand.
API's die te laat landen. De meest voorkomende oorzaak van een Flutter-team dat stilzit. Namaakendpoints kopen je een paar weken en houden daarna op iets te kopen.
Ontwerpen per beoordelingsronde. Drie rondes "laat nog één optie zien" op het beginscherm vertraagt elke fase erachter, want engineers kunnen niet tegen een bewegend doel bouwen.
Besluiteloosheid, inclusief stilte. Een sprint die niemand aan de kant van de klant installeert, is een sprint waarvan de misverstanden een maand later opduiken.
Drie van die vier zitten aan de kant van de klant. Dat is geen schuld afschuiven — het is waar de hefboom zit. Een bureau kan de engineering met misschien 10% samendrukken; een besluitvaardige klant kan de kalender met 30% samendrukken.
De checklist om sneller op te leveren
Zes knoppen, allemaal aan jou om aan te draaien:
- Leg de scope schriftelijk vast, en houd een schraplijst bij. De functies die uitdrukkelijk niet in versie één zitten zijn het waardevolste document van het project.
- Wijs één beslisser aan die dezelfde dag een ontwerp kan goedkeuren of een vraag kan beslechten.
- Breng de API mee, of accepteer dat hij op het kritieke pad ligt. Wordt de backend parallel gebouwd, leg de interface dan vroeg vast en bevries hem.
- Kom met een designsysteem — palet, typografische ladder, componentstaten — of begroot drie weken om er een te bouwen. Het overslaan verplaatst de kosten alleen maar.
- Zet winkelaccounts, privacyverklaringen en demogegevens in week één op, niet in de week dat je indient.
- Voeg capaciteit toe in plaats van druk, en voeg die vroeg toe. Flutter-developers inhuren in 2026 behandelt de modellen; teamuitbreiding is hoe we in dagen in plaats van maanden engineers aan een bestaand team toevoegen.
Eén anti-knop: developers die je in de laatste maand toevoegt maken een project later, niet eerder — ze leren de codebase van degene die toch al het knelpunt was.
Veelgestelde vragen
Wil je een planning voor jouw specifieke app?
Algemene bandbreedtes zijn prima om een kwartaal te begroten en nutteloos om een lancering te plannen. Wat je nodig hebt is een getal voor jouw functielijst, jouw backendsituatie en jouw winkelbeperkingen.
Stuur ons wat je bouwt en we komen terug met een afgebakende planning: de fasen, wat parallel loopt, wat we zouden schrappen om een datum te halen, en welke delen van jou afhangen in plaats van van ons. Is je datum niet haalbaar, dan zeggen we dat voordat je iets tekent.
Dat is onze praktijk Flutter-appontwikkeling: vaste scope, elke een tot twee weken een demonstreerbare build, en een planning die we verdedigen — zie ExtraETF, realtime marktdata in een gereguleerde markt, en Arcana, een AI-chatproduct dat de winkel haalde.
Vertel ons wat je bouwt en we geven je de datum, geen bandbreedte om je in te verstoppen.
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.