Wat een MVP echt kost in 2026: vaste prijs versus uurtarief

Je hebt een idee. Waarschijnlijk al een tijdje. Wat je nog niet hebt, is bewijs dat het werkt, en daar is een MVP precies voor bedoeld: de kleinste versie van je product waarmee echte gebruikers, of investeerders, je kunnen vertellen of je iets te pakken hebt, voordat je je vastlegt op het bouwen van het hele product.

Het lastige zit niet in het bouwen. Genoeg bureaus kunnen de code schrijven. Het lastige zit in het betalen ervan zonder dat de rekening al oploopt voordat je live bent, en zonder dat je na drie maanden ontdekt dat die "kleine MVP" stilletjes is uitgegroeid tot een veel groter, veel duurder project dan waar je oorspronkelijk mee instemde.

De uurtarief-valkuil

De meeste lokale ontwikkelbureaus werken met een uurtarief, doorgaans ergens tussen de €75 en €175 per uur, met een blended teamtarief (design, development, QA en projectmanagement samen) rond de €100 tot €150 per uur. Op papier klinkt dat behapbaar. Je maakt een snelle berekening, schat een paar honderd uur in, en komt uit op een bedrag dat redelijk lijkt.

In de praktijk kost een MVP die klein lijkt tijdens de kick-off vaak toch €30.000 tot €65.000 of meer, zeker zodra de scope halverwege verschuift, wat bijna altijd gebeurt. Een functie die simpel leek in de planningsfase blijkt toch drie extra schermen nodig te hebben. Een "leuk om te hebben" wordt stilletjes een "moet erin" zodra het ontwerp voor je ligt. Geen van deze individuele wijzigingen voelt op het moment zelf onredelijk, maar ze tellen snel op wanneer elk uur een prijskaartje heeft.

De reden hiervoor is structureel, niet persoonlijk. Het is zelden kwade wil aan de kant van het bureau. Bij een uurtarief kost elke vergadering, elke revisie, elke "kunnen we ook nog" je geld, en heeft het bureau weinig ingebouwde prikkel om het traject kort te houden, omdat hun omzet direct gekoppeld is aan het aantal geschreven uren. Je betaalt niet alleen voor de ontwikkeling. Je betaalt voor elk gesprek over de ontwikkeling, elke feedbackronde, elk Slack-bericht dat uitmondt in een belletje.

Waarom founders dit vooraf onderschatten

De meeste founders worden niet bedrogen door oneerlijkheid, ze worden bedrogen door optimisme. Iedereen gelooft oprecht in de schatting aan het begin. Het probleem is dat een uurtarief-contract geen natuurlijke rem heeft op scope creep: elke kleine toevoeging is technisch factureerbaar en op zichzelf technisch redelijk, en er is geen duidelijk moment waarop iemand zegt "wacht, dit is nu een ander project geworden." Tegen de tijd dat het totaalbedrag zichtbaar is, zit je al te ver in het traject om makkelijk terug te trekken, en heeft het bureau weinig sterke prikkel om het eerder aan te kaarten.

Wat een vaste prijs verandert

Wij bouwen MVP's tegen een vaste prijs, onszelf inbegrepen: we bouwden Asignu, ons eigen Europese e-handtekeningplatform, volgens exact dit proces, van een leeg scherm tot een product dat nu live staat met betalende klanten. We hebben dit model niet in theorie ontworpen. We gebruikten het eerst op ons eigen product, waardoor we elk onderdeel dat in de praktijk niet werkt zelf hebben ervaren voordat we het ooit aan een klant aanboden.

Een vaste prijs dwingt het gesprek vooraf af, in plaats van bij elke factuur. Voordat er een regel code wordt geschreven, krijg je een concreet voorstel: scope, planning en één bedrag. Geen onduidelijkheid over wat inbegrepen is, en geen prikkel aan onze kant om het project op te rekken, omdat de prijs niet verandert als het werk langer duurt dan verwacht. Dat risico ligt bij ons, niet bij jou.

Minstens zo belangrijk: voordat de bouw start, zie je gratis interactieve mockups van je MVP, en klik je er zelf doorheen. Je keurt het ontwerp goed voordat er één regel code wordt geschreven, niet nadat je al hebt betaald voor een versie waar je niet zeker over bent. Deze ene stap voorkomt de meeste dure verrassingen: tegen de tijd dat de ontwikkeling begint, heb je al ongeveer gezien wat je krijgt, en hoeft het bouwende team niet te gokken naar wat je bedoelde.

Hoe het proces er in de praktijk uitziet

Een typisch vaste-prijs-MVP-traject begint met een intakegesprek over je idee, je doelgroep en de kernfunctionaliteit die er echt toe doet voor een eerste versie, samen met een eerlijk gesprek over wat redelijkerwijs kan wachten tot een latere release. Daarna ontvang je een voorstel met een vaste scope, een vaste planning en één vaste prijs. Zodra dat is afgesproken, begint de designfase met interactieve mockups die je bekijkt en goedkeurt voordat er ontwikkeling plaatsvindt. Daarna volgt de daadwerkelijke ontwikkeling, met wekelijkse updates of demo's zodat je nooit weken hoeft te wachten om voortgang te zien, gevolgd door testen en livegang.

Betaling wordt doorgaans over het project verspreid in plaats van volledig vooraf of volledig achteraf: een deel bij de start, een deel zodra je de mockups goedkeurt, en de rest bij oplevering, zodat beide partijen in elke fase belang hebben bij een goed resultaat.

Wat je elke MVP-partner moet vragen voordat je tekent

Als je bureaus vergelijkt, scheiden een paar vragen meestal de vaste-prijs-partners van de verkapte uurtarief-bureaus. Wat gebeurt er als de scope halverwege verandert? Als het antwoord een nieuwe factuur per kleine wijziging is, zit je alsnog in uurtarief-territorium, maar dan met extra stappen. Zie en keur je het ontwerp goed voordat de bouw start, of pas achteraf? En wat valt buiten de prijs? Doorlopend onderhoud na livegang mag redelijkerwijs een aparte post zijn, omdat dat een open-eind verplichting is in plaats van een afgebakend project, maar ontwikkeling, design en livegang zouden niet uitgesloten of als extra's behandeld moeten worden.

De echte vraag die een MVP moet beantwoorden

Een MVP is bedoeld om één vraag te beantwoorden: werkt dit? Trekt het echte gebruikers aan, lost het het probleem op waarvan je denkt dat het dat oplost, is er hier een bedrijf om verder op te bouwen. Die vraag zou geen open-eind budget moeten vereisen om te beantwoorden, en de prijs die je betaalt om erachter te komen zou niet de grootste onzekere factor in het hele traject moeten zijn.