Wat kost een MVP bouwen en hoe snel kan het?
Wat kost het bouwen van een MVP en hoe snel kan het? De kostendrijvers, de fasen, de stack en wat bewust buiten scope blijft, vanuit een AI-native aanpak.
Kort antwoord
Wat een MVP kost hangt volledig af van de scope: het aantal kernflows, gebruikersrollen, externe koppelingen en of je web én mobiel wil. Een vast bedrag bestaat niet, je krijgt een prijs zodra de scope scherp is. De doorlooptijd meet ik in weken in plaats van maanden, omdat agents een groot deel van de code schrijven.
Wat het bouwen van een MVP kost, hangt af van de scope: het aantal kernflows, gebruikersrollen, externe koppelingen en of je web én mobiel wil. Een universeel bedrag bestaat niet, een offerte volgt zodra de scope scherp is. De doorlooptijd meet ik in weken in plaats van maanden, omdat agents een groot deel van de code schrijven.
Je hebt een idee en wil weten of het klopt voordat je er een jaar en een heel team in stopt. Het probleem: de meeste trajecten rekenen nog met maanden, vijf rollen en een overdracht per fase. De oplossing is een kleinere scope en een andere manier van bouwen. Ik ontwerp en bouw software vanuit de Rotterdam Science Tower en werk AI-native: agents schrijven een groot deel van de code, ik bepaal de architectuur, het product en de kwaliteitslat. Daardoor gaat het van idee naar productie in weken in plaats van maanden, zonder concessies aan kwaliteit, toegankelijkheid of snelheid.
Wat kost het bouwen van een MVP?
De prijs van een MVP volgt de scope, niet een standaardpakket. Twee ideeën die op een A4 even groot lijken, kunnen in bouwwerk een factor drie verschillen zodra je kijkt naar rollen, koppelingen en data.
Belangrijker dan het bedrag is de definitie. Een MVP is de kleinste werkende versie waarmee je één aanname test bij echte gebruikers. Het is geen uitgeklede versie van het eindproduct en geen demo. Zodra een MVP "alles alvast een beetje" moet kunnen, stijgt de prijs en daalt de leerwaarde.
Richtbedragen die online rondzingen zeggen daarom weinig. Wat wél voorspelbaar is, zijn de kostendrijvers:
- Aantal gebruikersrollen. Eén rol is één set schermen. Drie rollen betekent drie keer rechten, drie keer randgevallen, drie keer testen.
- Externe koppelingen. Betalingen, transactionele e-mail, boekhouding, een leverancier-API: elke integratie heeft eigen foutafhandeling.
- Realtime of offline eisen. Live updates en offline-first werken zijn architectuurbeslissingen, geen features die je er later bij klikt.
- Compliance. AVG-gevoelige data, verwerkersovereenkomsten of zware identificatie-eisen kosten tijd in ontwerp en review.
- Web én mobiel tegelijk. Twee platformen betekent twee releasepaden en twee keer testen.
Wil je een reëel getal, dan is de snelste route: één zin over de aanname die je test, plus wie de eerste gebruikers zijn.
Welke posten zitten er in de prijs van een MVP?
In elk MVP-traject gaat het geld naar meer dan alleen programmeren. Dat is precies waarom offertes zo kunnen verschillen: de ene splitst het uit, de andere verstopt het in een uurprijs.
| Post | Wat er gebeurt |
|---|---|
| Discovery en scope | De aanname scherp krijgen, flows kiezen, snoeien in wensen |
| UX/UI en designsysteem | Schermen, componenten, states, contrast en typografie |
| Frontend | De kernflows bouwen, web of mobiel |
| Backend en datamodel | Datamodel, API, businesslogica |
| Auth en rechten | Registratie, login, sessies, rollen |
| Integraties | Betalingen, e-mail, analytics |
| Deploy en livegang | Productieomgeving, monitoring, releaseproces |
Houd daarnaast rekening met ruimte voor iteratie ná de eerste gebruikers. Aan de kernflow verandert altijd iets zodra echte mensen hem gebruiken. Wie daar geen rekening mee houdt, betaalt dat later als meerwerk.
Hoe snel kan een MVP live staan met AI-agents?
Weken in plaats van maanden. Dat is de belofte van een AI-native werkwijze, en ze rust op twee dingen.
Eerst: agents schrijven een groot deel van de code. Repetitief werk zoals CRUD-endpoints, formulieren, validatieschema's, testopzet en migraties gaat vele malen sneller dan met de hand. Mijn tijd verschuift daardoor naar de dingen die de uitkomst bepalen: architectuur, datamodellering, review en productkeuzes.
Tweede reden: één aanspreekpunt in plaats van een team van vijf. Geen overdracht tussen designer, frontender, backender, tester en projectmanager. Minder meetings, minder afstemmingsverlies, minder overhead. De exacte doorlooptijd hangt af van dezelfde factoren als de prijs: hoeveel flows, hoeveel rollen, hoeveel koppelingen.
Hoe ziet een MVP-traject er in fasen uit?
Elk MVP-traject doorloopt vier fasen, en de eerste bepaalt of de rest soepel gaat.
- Scope, datamodel en architectuur. Welke aanname testen we, welke flows zijn daarvoor minimaal nodig, hoe ziet de data eruit en welke technische keuzes liggen daarmee vast.
- Kernflows bouwen. Authenticatie, de hoofdflow, de schermen die er echt toe doen. Werkende versies op een testomgeving, zodat je stuurt op wat je ziet in plaats van op wat je hoopt.
- Integraties en kwaliteitscheck. Betalingen of e-mail erin, toegankelijkheid nalopen, performance meten en bijsturen, monitoring aan, live.
- Iteratie. Echte gebruikers erop, aanpassen op basis van wat er gebeurt.
Wil je zien met welke technieken ik dat doe, bekijk de stack en werkwijze.
Welke stack gebruik ik voor een MVP en waarom?
Eén stack, TypeScript van voor tot achter, zodat types en validatie gedeeld zijn en agents consistent werken binnen duidelijke kaders.
- Web: Next.js en React. Server rendering, goede uitgangspositie voor Core Web Vitals, eenvoudig te deployen.
- Mobiel: React Native met Expo. Eén codebase voor iOS en Android.
- Backend: NestJS met PostgreSQL. Duidelijke modulestructuur en relationele data die meegroeit als het product slaagt.
- Auth, database en storage: Supabase. Login, rechten en bestandsopslag zonder ze zelf te bouwen.
- Content: Payload of Drupal, als redactionele content onderdeel van het product is.
Deze keuzes zijn bewust saai. Een MVP moet snel klaar zijn en daarna nog uitbreidbaar zijn door iemand anders dan ik.
Wat blijft bewust buiten scope van een MVP?
Alles wat je aanname niet test. Dat is de enige regel die planning en budget echt bewaakt.
Vaak buiten scope: uitgebreide admin-dashboards, rolbeheer voor meerdere gebruikersgroepen, meertaligheid, een release in de App Store en Play Store, uitgebreide rapportage en migraties van legacy data. Dat zijn geen afzeggingen maar uitgestelde beslissingen. Klopt de aanname, dan bouw je ze later met kennis uit echt gebruik in plaats van uit aannames.
Waar ligt de kwaliteitslat die een agent niet bewaakt?
Agents schrijven code, ze nemen geen verantwoordelijkheid. De lat ligt bij mij, op zes punten:
- Architectuur. Modulegrenzen, waar logica hoort, wat je later wil kunnen vervangen.
- Datamodellering. Een fout datamodel is de duurste fout in een MVP, want alles erboven volgt de vorm.
- Toegankelijkheid. WCAG-uitgangspunten, volledige toetsenbordnavigatie, contrastverhoudingen, focusstates, semantische HTML.
- Performance. Core Web Vitals meten, bundelgrootte bewaken, images en fonts netjes laden.
- Securityreview. Rechten per endpoint, invoervalidatie, omgang met secrets, wat er in logs belandt.
- Productbeslissingen. Wat wel en niet in de eerste versie hoort. Een agent zegt nooit uit zichzelf nee.
De korte versie
Wat een MVP bouwen kost, bepaalt de scope: kernflows, rollen, integraties, compliance en platformen. Hoe snel het kan, bepaalt dezelfde scope plus de manier van werken. Met een AI-native aanpak dalen de bouwuren en gaat de aandacht naar architectuur, toegankelijkheid en productkeuzes, waardoor een MVP in weken live staat in plaats van in maanden.
Praktische volgende stap: schrijf in één zin op welke aanname je wil testen en wie de eerste tien gebruikers zijn. Met die zin is een inschatting van scope, prijs en doorlooptijd mogelijk. Meer over mijn werk en achtergrond lees je op de site van Senna Oudshoorn.
Veelgestelde vragen
Waarom kan niemand vooraf een vast bedrag voor een MVP noemen?
Omdat de prijs de scope volgt. Twee ideeën die op papier even groot lijken, verschillen fors zodra je kijkt naar het aantal gebruikersrollen, externe koppelingen, eisen rond realtime of offline werken en privacy. Een serieus bedrag komt pas nadat de aanname en de minimale flows scherp zijn.
Hoe lang duurt het bouwen van een MVP?
Dat hangt af van het aantal kernflows, rollen en integraties. Met een AI-native werkwijze, waarbij agents een groot deel van de code schrijven, gaat een idee in weken naar productie in plaats van in maanden. De fasen zijn steeds gelijk: scope en datamodel, kernflows bouwen, integraties en kwaliteitscheck, daarna iteratie.
Wat maakt een MVP duurder dan verwacht?
Vijf dingen: meerdere gebruikersrollen, externe koppelingen zoals betalingen of e-mail, eisen rond realtime of offline werken, compliance zoals AVG en zware identificatie, en web plus mobiel tegelijk willen. Elke extra rol of integratie vermenigvuldigt de randgevallen en testsituaties, en daarmee het werk achter de schermen.
Is een MVP die met AI-agents is gebouwd wel onderhoudbaar?
Ja, mits een mens de architectuur en het datamodel bepaalt. De agents werken binnen kaders die ik vaststel: TypeScript van frontend tot backend, duidelijke modulegrenzen in NestJS en een relationeel datamodel in PostgreSQL. Architectuur, toegankelijkheid, performance en securityreview blijven mijn verantwoordelijkheid, niet die van de agent.
Wat spreek je vooraf af over de oplevering?
Leg vast welke aanname de MVP test, welke flows daarbij horen en wat bewust buiten scope blijft, zoals admin-dashboards, meertaligheid of een app-store release. Bespreek ook eigendom van de code, de productieomgeving en wat er na de eerste gebruikers gebeurt. Dat voorkomt discussie over meerwerk.