MVP-ontwikkeling is het bouwen van de kleinste app die de vraag kan beantwoorden die je bedrijf werkelijk heeft: gaat iemand dit gebruiken, gaat iemand ervoor betalen, is de flow die je voor ogen had de flow die mensen willen. Het verschilt op één structureel punt van gewone appontwikkeling: de oplevering is geen set functionaliteiten, het is een antwoord. Alles wat je niet dichter bij dat antwoord brengt, is scope waarvoor je twee keer betaalt — één keer om het te bouwen en één keer om het te onderhouden tot je het weggooit.

Een op Flutter kost doorgaans twee tot drie maanden van kickoff tot een live winkelvermelding, en komt op € 12-24K. Beide cijfers komen uit onze kostengids, en waar die maanden fase voor fase heen gaan staat in onze doorlooptijdanalyse: we publiceren ze liever en laten ons erop aanspreken dan dat we openen met "dat hangt ervan af".

Flutter doet er in deze fase meer toe dan in welke andere ook. Een MVP toetst marktvraag, geen platforms, en je weet vooraf niet uit welke winkel je eerste honderd echte gebruikers komen. Eén codebase zet de app in allebei, en dat is het verschil tussen een idee valideren en een idee valideren op Android.

Waarmee een MVP live gaat

  • 5–8 kernfunctionaliteiten — die waar de vraag van afhangt, en geen andere
  • iOS en Android, vanuit één codebase en één team
  • Een managed backend in plaats van er zelf een te schrijven, tenzij het product echt anders eist
  • Interface uit een componentbibliotheek — Material en Cupertino, gestyled in plaats van hertekend, zodat ontwerp niet op het kritieke pad ligt
  • Analyse en crashrapportage vanaf dag één, want een MVP zonder instrumentatie beantwoordt niets
  • Een vermelding in beide winkels, waarbij het indienen als fase wordt behandeld en niet als een knop

Wie je MVP bouwt

Twee dingen onderscheiden een team dat een MVP kan opleveren van een team dat apps bouwt.

Een volledig product, ontworpen en opgeleverd in zeven weken

OneTwoDo is een tweezijdige marktplaats voor lokale diensten, gebouwd voor Perform Connect Studios S.L.: advertenties voor schoonmaak, klussen, loodgieterswerk en de rest, geplaatst en bekeken door mensen in dezelfde buurt. Wij bouwden het van begin tot eind: productontwerp, de Flutter-client en alles waar het op draait. Zeven weken.

Het staat hier vanwege de manier waarop het werd afgebakend. Een tweezijdige marktplaats impliceert normaal eerst een backendteam en pas daarna iets anders — accounts, sessies, een database met advertenties, opslag voor foto's, een server om het achter te zetten — en daar gaan de eerste drie maanden van een klein team meestal heen. OneTwoDo ging live zonder die laag te schrijven: Firebase Authentication voor accounts, Firestore voor advertenties en profielen, Cloud Storage voor foto's, Analytics en Crashlytics in plaats van dashboards die je anders zelf bouwt. Niets om in te richten, te patchen of piket voor te draaien.

Die keuze maakte het mogelijk dat één team ontwerp, client en backend tegelijk droeg, en dat bleef lonen: prijzen in meerdere valuta, per advertentie gelokaliseerde omschrijvingen en een feed gefilterd op taal en locatie waren stuk voor stuk clientwerk bovenop een datalaag die er al was, in plaats van een backendticket gevolgd door een clientticket. Het volledige verhaal staat in de case.

We publiceren de cijfers in plaats van "dat hangt ervan af"

Elk bureau beantwoordt "hoe lang" en "hoeveel" met een bandbreedte die zo breed is dat je er niets aan hebt. De onze staan op deze pagina, op de pagina Flutter-appontwikkeling en fase voor fase uitgesplitst in Hoe lang duurt het om een Flutter-app te bouwen? en Wat een Flutter-app kost in 2026. Past jouw project er niet in, dan zeggen we dat tijdens het afbakenen — het enige moment waarop die informatie je iets waard is.

Ander werk van deze omvang: Arcana, een AI-tarotcompagnon waarvan de Flutter-client — een streamende chat die duizenden berichten op 60 fps vasthoudt — drie weken kostte; en we hebben het zesweekse plan om een Telegram-bot met een bestaand publiek in beide winkels te krijgen opgeschreven; dat is een samenstelling van werk dat we hebben gedaan en niet één klant, en het is snel juist omdat de productvraag elders al beantwoord was.

Wat een MVP echt vraagt

Zes dingen bepalen of een MVP in drie maanden live gaat of drie keer zo lang duurt als waarop hij was afgebakend.

Een schraplijst waar je je echt aan houdt

De ondergrens van twee maanden is echt, maar voorwaardelijk: een scope die op één pagina past, één persoon die een besluit kan nemen zonder een commissie bijeen te roepen, en geen nieuw technisch risico — geen videopijplijn, geen machine learning op het toestel, geen betaalinfrastructuur in een nieuw rechtsgebied. Drie maanden komt vaker voor, en die extra maand is bijna nooit "de code was lastiger". Het is een betaalflow die in week vier opdook, een niet-begrote ontwerpronde, of twee weken wachten op API-toegang.

Daarom is de schraplijst de oplevering van het afbakenen en geen voetnoot erbij. We schrijven net zo expliciet op wat erbuiten valt als wat erin zit, en we gaan in tegen toevoegingen halverwege de bouw — niet om lastig te doen, maar omdat elke kleine toevoeging een week is, en vier kleine toevoegingen het verschil zijn tussen dit kwartaal lanceren en het volgende.

De scope die je niet ziet

"Een simpele app om trainingen bij te houden" is vijf schermen in je hoofd. In de praktijk is het onboarding, authenticatie met e-mail, Google en Apple — elk met eigen randgevallen — de functionaliteit zelf, instellingen, profiel, accountverwijdering (door beide winkels verplicht gesteld) en een betaalflow als er geld mee gemoeid is. Niets daarvan is opvulling, en niets daarvan is waar je aan dacht toen je de app beschreef.

Dit vroeg benoemen is het grootste deel van goed afbakenen. Hier vindt ook het eerlijke gesprek over de bandbreedte plaats: de onzichtbare scope is ruwweg constant, dus slokt hij een veel groter deel op van een bouw van twee maanden dan van een bouw van zes.

Een backend die je niet zelf hoefde te schrijven

Voor de meeste MVP's is een managed backend geen concessie maar de juiste technische keuze, en OneTwoDo is het bewijs. Firebase, Supabase of een dunne -service over een managed database dekt accounts, data, bestanden en analysegegevens zonder een team dat het draaiende houdt, en het schaalt ruim voorbij het punt waarop een MVP zijn vraag al beantwoord heeft.

Wanneer we het afraden: als de kern van het product iets is wat een managed backend niet kan — zware bedrijfslogica, realtime op schaal, een toezichtregime dat voorschrijft waar data fysiek staat. We zeggen je aan welke kant je staat vóór de schatting, want het verschuift het bedrag.

Instrumentatie, anders beantwoordt de MVP niets

Een MVP bestaat om bewijs te leveren. Hem uitbrengen zonder analyse, crashrapportage en een vastgelegde set events is het hele budget uitgeven en er een mening voor terugkrijgen in plaats van data. We spreken tijdens het afbakenen de handvol events af die bij je werkelijke vraag horen — activatie, de kernhandeling, de uitval waar je bang voor bent — en koppelen ze vóór de lancering, niet nadat de eerste groep gebruikers al is gekomen en gegaan.

Wat we weigeren te schrappen

Een MVP verdient zijn snelheid door functionaliteit te schrappen, niet door engineering te schrappen. Wat blijft, ongeacht de scope: modulegrenzen waardoor v2 kan groeien zonder herbouw, vanaf de eerste week zodat bouwen één commando is, tests op de paden waar fout zijn geld kost, en benoemde foutstatussen in plaats van een draaiend wieltje dat nooit stopt.

Dit is het verschil tussen een MVP en een prototype, en daar loont het om precies te zijn. Een prototype is bewust wegwerpbaar. Een MVP is de eerste versie van een product dat je wilt houden, dus moet de code code zijn die je kúnt houden. En de reden dat "we ruimen het na de lancering wel op" zo zelden gebeurt, is dat een gevalideerd product onmiddellijk werk oplevert dat urgenter is dan opruimen.

Indienen bij de winkels is een fase

Reken op één tot twee weken. De review zelf duurt meestal 24 tot 48 uur, maar het werk eromheen niet: winkelvermeldingen, schermafbeeldingen voor elk verplicht toestelformaat, een privacyverklaring en de verklaringen over gegevensveiligheid die beide winkels inmiddels eisen, en een route om je account te verwijderen waar Apple op controleert. Teams die dit in de laatste week ontdekken, lopen vertraging op om redenen die niets met hun app te maken hebben.

Waarom Flutter voor een MVP

Het eerlijke argument voor Flutter hier:

EisHoe Flutter dat aanpakt
Beide winkels, één budgetÉén codebase, ruwweg 30–40% minder dan twee native trajecten — de grootste hefboom op MVP-schaal
Itereren terwijl gebruikers meekijkenHot reload binnen een seconde: een wijziging staat op het toestel voordat een native herbouw is opgestart
Ontwerp buiten het kritieke padMaterial- en Cupertino-widgets dragen de interface tot je een eigen designsysteem hebt verdiend
Eén team om aan te nemenFlutter-engineers, geen iOS-team plus Android-team plus de coördinatie ertussen
v2 zonder herbouwDe MVP-codebase ís de productcodebase: dezelfde app groeit door naar het zakelijke niveau in plaats van vervangen te worden

Waar native nog wint: als de vraag die je valideert zélf een platformspecifieke mogelijkheid is — een diepe Apple Watch-ervaring, een product rond widgets, iets op een API die maar op één platform bestaat — dan gaat de cross-platformbesparing niet over de kern en kan native het eerlijke antwoord zijn. Wij zeggen het wanneer dat zo is. De algemene dienstpagina is Flutter-appontwikkeling.

Hoe we werken

MVP met vaste scope. Wij zijn verantwoordelijk voor de hele oplevering — verkenning, ontwerp, architectuur, bouw, indienen bij de winkels. Het beste wanneer je een afgebakende scope wilt overdragen aan één team dat op de lanceerdatum aanspreekbaar is. Hoe dat er week na week uitziet, staat in ons ontwikkelproces.

Van prototype naar productie. Draait er al iets — een build uit Cursor, Bolt of Lovable, of een lang weekend met een AI-agent — dan is de productvraag mogelijk al deels beantwoord en is het werk anders: eerst een audit, daarna het gat tussen "werkt in de demo" en "veilig voor echte gebruikers". Die route is de audit van AI-code, en het draaiboek staat in Een met AI gebouwd prototype naar productie brengen.

Teamuitbreiding. Onze engineers voegen zich bij jouw team, in jouw repository en jouw sprints, onder jouw aansturing. Het beste wanneer je al technische leiding hebt en Flutter-capaciteit tekortkomt — zie teamuitbreiding en onze gids over Flutter-developers inhuren, die eerlijk is over wanneer je ons niet moet inzetten.

Welke route het ook wordt, we sturen binnen twee werkdagen na het doorgronden van de eisen een afgebakende offerte.

Veelgestelde vragen

Veelgestelde vragen van oprichters die een eerste release op Flutter afbakenen.

Een minimum viable product is de kleinste app die een concrete bedrijfsvraag kan beantwoorden: gaan mensen dit gebruiken, gaan ze betalen, is dit de flow die ze willen. De nadruk ligt op viable en niet op minimum: het moet goed genoeg zijn dat de reactie van een echte gebruiker iets waars zegt, en daarom is een MVP geen prototype en geen klikbare mockup. In de praktijk zijn dat 5 tot 8 kernfunctionaliteiten, een echte backend, analyse gekoppeld aan de vraag die je stelt, en een live vermelding in de winkels. Alles daarbovenop is scope waarvoor je twee keer betaalt: één keer om te bouwen en één keer om te onderhouden tot je het weggooit.
Twee tot drie maanden van kickoff tot een live winkelvermelding, voor een Flutter-MVP op zowel iOS als Android. De ondergrens van twee maanden is echt maar voorwaardelijk: een scope die op één pagina past, één persoon die besluiten neemt zonder commissie, en geen nieuw technisch risico zoals een videopijplijn, machine learning op het toestel of betaalinfrastructuur in een nieuw rechtsgebied. Drie maanden komt vaker voor, en die extra maand zit zelden in de engineering. Het is een betaalflow die in week vier opdook, een niet-begrote ontwerpronde, of twee weken wachten op toegang tot andermans API.
Ons MVP-niveau staat op deze pagina en op de pagina Flutter-appontwikkeling in plaats van het alleen op aanvraag te noemen, en het dekt 5 tot 8 functionaliteiten op iOS en Android met een managed backend en een interface uit een componentbibliotheek. Wat het bedrag beweegt is eerst scope en daarna koppelingen: elke serieuze koppeling met derden is één tot twee weken, en de onzichtbare scope van onboarding, authenticatie, instellingen, accountverwijdering en betalingen is ruwweg constant, dus die neemt bij een kleine bouw een groter deel in dan bij een grote. De volledige opbouw staat in onze gids over de kosten van Flutter-appontwikkeling.
Erin: de functionaliteiten waar de vraag van afhangt, één schoon pad erdoorheen, analyse op de momenten die de vraag beantwoorden, en de basisvoorzieningen die de winkels je niet laten overslaan, waaronder een route voor accountverwijdering. Eruit: de tweede gebruikersrol, het beheerpaneel dat je een halfjaar in een spreadsheet kunt draaien, het eigen designsysteem, offline werken, en elke functionaliteit die je verantwoordt met een gebruiker die je nog niet hebt ontmoet. De bruikbare toets is of iets weglaten verandert wat je van de lancering leert. Zo niet, dan is het v2 — en die lijst opschrijven is de oplevering van het afbakenen, geen voetnoot.
Niet als hij als MVP is gebouwd en niet als prototype. Een prototype is bewust wegwerpbaar; een MVP is de eerste versie van een product dat je wilt houden, dus hoort hij modulegrenzen te hebben waarmee functionaliteit kan groeien, continuous integration vanaf de eerste week, tests op de paden waar fout zijn geld kost, en echte foutstatussen. Dat kost dagen, geen weken, en het is het verschil tussen v2 als uitbreiding en v2 als opnieuw beginnen. Wat we voor snelheid wél schrappen zijn functionaliteiten, eigenheid van het ontwerp en infrastructuur die je kunt huren — nooit de structuur van de code zelf.
Ja, en steeds vaker beginnen projecten zo. Een build uit Cursor, Bolt of Lovable betekent vaak dat de productvraag al deels beantwoord is, wat echt waardevol is — maar het gat tussen werken in een demo en veilig zijn voor echte gebruikers is concreet en voorspelbaar, en clustert rond blootgestelde sleutels en ontbrekende autorisatie, ongecachete API-aanroepen die het verbruik vermenigvuldigen, en gevoelige data die in logs of bij derden belandt. De route is dan eerst een audit en daarna het werk om live te gaan, in plaats van een herbouw die weggooit wat je al hebt geleerd.
Meestal wel, en dit is juist in deze fase het sterkste argument voor Flutter. Een MVP toetst marktvraag en geen platforms, en je weet zelden vooraf uit welke winkel je eerste echte gebruikers komen — dus in één winkel uitbrengen betekent je idee valideren bij het publiek van één platform en gissen naar het andere. Omdat één Flutter-codebase beide apps oplevert, zijn de meerkosten van de tweede winkel klein, en dat is precies de afweging die een eerste release wil. De uitzondering is een product waarvan de kern een platformspecifieke mogelijkheid is; daar gaat de cross-platformbesparing niet over de kern.

Lees de fase-voor-fase-analyse in Hoe lang duurt het om een Flutter-app te bouwen?, of bekijk de OneTwoDo-case om te zien hoe een volledig product in zeven weken werd ontworpen en opgeleverd.