Clutch Developer
NL
Book a call

Wat het bouwen van een MVP in 2026 werkelijk kost

Meeste MVP-offertes beantwoorden een ander vraag dan wat jij stelt. Dit is waaruit het getal werkelijk bestaat.

Elke founder stelt deze vraag, en vrijwel elk antwoord is nutteloos. "Het hangt ervan af" is waar en niet nuttig. "€ 50.000" is specifiek en waarschijnlijk fout. Het probleem is dat MVP voor de vrager iets anders betekent dan voor de offertesteller.

Dus laten we het getal opsplitsen in de onderdelen waaruit het werkelijk bestaat.

De drie dingen die je werkelijk koopt

Elke offerte die je krijgt, is een combinatie hiervan, ongeacht of de uitsplitsing getoond wordt.

  1. Besluiten. Wat wordt gebouwd, wat wordt weggelaten, waar het voor is. Dit is het dure onderdeel en wordt bijna nooit apart opgevoerd.
  2. Bouw. Die besluiten omzetten in werkende software. Dit is het onderdeel waarvoor iedereen denkt te betalen.
  3. Risico. De buffer die de leverancier toevoegt omdat ze jouw codebase niet kennen, jouw stakeholders niet kennen, of hoeveel wijzigingen nog gaan komen.

Een dure offerte is meestal vol item drie. Een goedkope offerte heeft meestal item één overgeslagen, en je betaalt later in wijzigingsverzoeken.

Ruwe bereiken, eerlijk gezegd

Dit zijn Europese tarieven voor senior werk in 2026. Amerikaanse agencytarieven lopen meestal 1,5–2× hoger voor gelijkwaardige senioriteit; offshoretarieven zijn lager, maar verplaatsen de kosten van de factuur naar jouw eigen management-uren, wat zelden in rekening wordt gebracht.

  • Een enkele gevalideerde flow — één core journey, echte backend, verzendbaar naar een testgroep: € 7.000–15.000.
  • Een solide consumer MVP — auth, een core loop, betalingen, push, store release: € 25.000–60.000.
  • Een B2B-product met echte integraties — SSO, rollen, een externe API die je niet controleert, een beheeroppervlak: € 60.000–150.000.
  • Alles wat gereguleerde gegevens raakt — gezondheid, financiën, identiteit — voeg 30–50% toe voor compliancewerkzaamheden die onzichtbaar zijn in de demo.

Als een leverancier je een vast getal geeft zonder te vragen waarvoor het product is, prijzen ze item twee en hopen dat items één en drie niet toeslaan. Dat zal wel gebeuren.

Wat het getal werkelijk doet stijgen

Min of meer in deze volgorde:

  • Integraties met systemen die je niet controleert. Een betalingsprovider, een legacy ERP, iemands ongedocumenteerde API. Dit is de meest voorkomende bron van overschrijding, omdat de inzet pas duidelijk wordt als je erin begint.
  • Het aantal mensen dat nee kan zeggen. Elke extra goedkeurder voegt agenda-tijd toe, en agenda-tijd is geld op dagtarief. Een project met drie stakeholders is niet 50% duurder dan één met twee — het is vaak dubbel.
  • Design dat nog niet is bepaald. "We werken de schermen uit onderweg" is ervoor kiezen om hetzelfde scherm drie keer te betalen.
  • Native vs cross-platform. Echt, maar meestal kleiner dan mensen verwachten — zie Native vs Flutter vs React Native.
  • Je eigen responsiviteit. Een team dat twee dagen op je antwoord wacht, berekent die twee dagen mee.

De goedkoopste MVP is degene die je niet twee keer bouwt

De duurste projecten die ik heb gezien, waren niet de projecten met grote budgetten. Ze waren de projecten die iets goedkoop afleverde dat niemand wilde, en daarna opnieuw moest beginnen — nu met minder geld en minder geduld van de raad.

Voordat je offertes vergelijkt, zorg ervoor dat je kunt antwoorden: welk één ding moet waar zijn om dit voort te zetten? Als de MVP dat niet test, is de prijs irrelevant.

Hoe je offertes vergelijkbaar maakt

Stuur elke leverancier dezelfde drie dingen en de getallen die je terug krijgt, hebben eindelijk betekenis:

  • De ene user journey die het meest uitmaakt, van begin tot eind in duidelijke taal beschreven.
  • De externe systemen, benoemd, met aantekening of je ze controleert.
  • De datum waarop het voor echte gebruikers beschikbaar moet zijn, en wat gebeurt als dat niet lukt.

Leveranciers die met vragen terugkomen in plaats van een getal, zijn degenen met wie je wilt praten.

Een praktijkvoorbeeld

Een founder kwam vorig jaar naar me toe die een marktplaats-app wilde bouwen. Twee zijden, betalingen, chat, reviews, ratings, een web-beheerpanel. Drie bureaus hadden offertes gegeven tussen € 90.000 en € 140.000, en alle drie gaven eerlijke prijzen voor wat was omschreven.

Het onzekere was of leveranciers wel zouden deelnemen. Al het andere — de betalingen, de chat, de ratings — was alleen de moeite waard om te bouwen als dat waar zou zijn, en niets testde het.

Wat we werkelijk bouwden, in één twee-weekse sprint: een inschrijvingsstroom, een catalogus-overzicht, en een contactknop die WhatsApp opende. Geen betalingen, geen chat, geen ratings, geen beheerpanel. Rond € 8.000.

Dertig leveranciers meldden zich aan in de eerste twee weken, en bijna allemaal probeerden ze het gesprek onmiddellijk van het platform af te halen. Dat's een bevinding ter waarde van honderdduizenden, en het kostte bijna niets. De volledige bouw gebeurde later, bewust, met het disintermediëringsprobleem ontworpen in plaats van in maand vijf ontdekt.

De € 90.000-offerte was niet fout. Het was een correct prijskaartje voor de verkeerde omvang, en geen tariefsonderhandeling zou dat hebben opgelost.

Vijf vragen om te stellen voordat je een offerte aanvaardt

  1. Wat heb je aangenomen dat ik je niet heb verteld? Elke schatting rust op aannames. Ze opschrijven maakt ze van toekomstige excuses tot huidige risico's.
  2. Welk onderdeel hiervan ben je het minst zeker over? Een eerlijke leverancier noemt er onmiddellijk een. Een leverancier die zegt "geen daarvan" heeft er niet over nagedacht, en dat ga je later betalen.
  3. Wat zou je schrappen als het budget de helft was? Het antwoord onthult wat ze essentieel achten — en of ze begrijpen wat het product voor is.
  4. Wie schrijft de code, en welk percentage van hun week krijg ik? De tweede helft van die vraag is degene die ertoedoet. "Een senior lead" op één dag per week is geen senior lead.
  5. Wat gebeurt er als we het oneens zijn of iets inbegrepen is? Die dag zal komen. Beter om het mechanisme nu te kennen, terwijl iedereen nog vriendschappelijk is.

Waarom goedkope offertes duur worden

Het patroon is consistent genoeg om voorspelbaar te zijn. Een lage offerte wint op prijs, dan volgt de werkelijkheid:

  • Maand één: dingen gaan snel, omdat de gemakkelijke 60% echt gemakkelijk is en iedereen gemotiveerd is.
  • Maand twee: de onvoorziene integratie blijkt een account, een contract, en een sandbox nodig te hebben die drie weken duurt om in te richten.
  • Maand drie: wijzigingsverzoeken beginnen. Elk is afzonderlijk redelijk en samen gelijk aan het verschil tussen de goedkope en dure offerte.
  • Maand vier: je kiest tussen meer betalen en iets verzenden waar je je voor schamen.

Je hebt geen geld bespaard — je hebt uitgesteld om de werkelijke prijs te ontdekken. Dat uitstel kost ook wat: runway die opgebruikt wordt en de reputatie die je verspilt met je investeerders.

Een noot over vaste prijzen

Een vaste prijs is geen korting — het is een overdracht van risico. De leverancier prijst het risico van ongelijk hebben, en je betaalt voor die zekerheid. Of het de moeite waard is, hangt af van hoe goed het werk is gedefinieerd, wat exact het onderwerp is van vaste prijs vs tijd en materiaal.

Wat ik zou zeggen is: als een leverancier een prijs vaststelt zonder het werk te begrijpen, beschermt de vaste prijs hen, niet jou. De omvang zal simpelweg krimpen totdat het past.