MVP laten ontwikkelen in 2026: kosten, scope en verborgen kosten

Het korte antwoord: bij mij kost een MVP met een smalle scope 1 900–9 300 € tegen een vaste prijs en duurt het 2 tot 6 weken. Een eenvoudigere marketingsite of landingspagina kost 1 500–3 500 €. Grotere producten krijgen geen ene grote offerte, maar worden in fasen opgedeeld. Je betaalt dus telkens voor een werkend, opleverbaar deel in plaats van voor een belofte.

Dat is mijn antwoord. Het langere, eerlijke antwoord is dat er op de vraag "wat kost een MVP" geen universeel bedrag bestaat, want de prijs wordt niet bepaald door de techniek, maar door hoe de scope is gedefinieerd. Dit artikel legt uit waar de grote verschillen tussen offertes vandaan komen, wat een project in deze range realistisch omvat en hoe je kosten drukt zonder de kansen van je product te drukken.

Waarom MVP-offertes uiteenlopen van 5 000 € tot zescijferige bedragen

Vraag vijf partijen om een prijs voor "een MVP" en je krijgt misschien vijf bedragen die 10 tot 50 keer van elkaar verschillen. Dat betekent niet per se dat iemand liegt. Elke partij kan een ander product hebben geprijsd.

De definitie van de scope is het echte product. "Een app waarin gebruikers afspraken boeken" klinkt als één zin, maar elke verduidelijkende vraag voegt een stuk werk toe:

• Inloggen: alleen e-mail en wachtwoord, of ook Google/Apple, wachtwoord resetten, e-mailverificatie?
• Betalingen: één Stripe-checkout, of abonnementen, terugbetalingen, facturen, btw?
• Rollen: één type gebruiker, of klanten, aanbieders en beheerders, elk met een eigen weergave?
• Beheerpaneel: beheer je de data rechtstreeks in de database, of heb je een interface nodig voor iemand zonder technische kennis?
• Integraties: agendasynchronisatie, sms, CRM, boekhouding. Elke integratie is een eigen miniproject.
• Mobiel: responsieve web, of native apps in twee stores met twee reviewprocessen?

Elk "ja" kan er dagen werk bij doen. Een partij die overal "ja" van uitgaat, prijst een platform. Een partij die overal "nee" aanneemt, prijst een prototype. Beiden kunnen het "jouw MVP" noemen.

Wie de offerte maakt, verandert ook het bedrag:

• Bureaus prijzen teams. Een bureauvoorstel kan projectmanagement, ontwerp, meerdere developers en QA bevatten, omdat het team hun verkoopeenheid is. Je betaalt voor die structuur, die per maand meer kan kosten dan een volledige MVP met smalle scope van één specialist.
• Freelanceplatforms prijzen uren. Een uurtarief kan per eenheid goedkoop lijken, maar zonder plafond blijft het totaal open: hoe langer het duurt, hoe meer je betaalt.
• Bouwers met een vaste prijs prijzen een resultaat. Een vastgelegde scope, een prijs, een deadline. Het inschattingsrisico voor de afgesproken scope ligt bij de bouwer. Zo werk ik, en dit is het model dat ik zelf als koper zou kiezen.

Vergelijk dus eerst waar de bedragen voor zijn, voordat je ze naast elkaar legt. Een offerte van 5 000 € en een offerte van 50 000 € zijn meestal geen concurrerende aanbiedingen, het zijn verschillende producten onder dezelfde naam.

Wat een MVP van 1 900–9 300 € realistisch omvat

Eerlijkheid vraagt om een duidelijke grens, dus hier is ze.

Een MVP met smalle scope voor de instapprijs omvat doorgaans:

• Eén kernflow, van begin tot eind goed gebouwd, bijvoorbeeld: een gebruiker registreert zich, doet het ene wat je product belooft en betaalt ervoor
• Een nette, responsieve interface (geen sjabloon die je voor de voeten wordt gegooid, maar ook geen kunstproject van een designbureau)
• Basis-login, als de flow dat nodig heeft
• Eén betaalroute (bijvoorbeeld een Stripe-checkout of -abonnement)
• Een eenvoudige manier om de data te zien en te beheren
• Deployment, domein, SSL: het product staat live op internet en "werkt niet alleen op mijn machine"
• Aangesloten analytics, zodat je na de lancering echt kunt leren

Wat een project meestal in fasen verschuift:

• Meerdere gebruikersrollen met verschillende dashboards (het klassieke voorbeeld: marktplaatsen)
• Realtimefuncties: chat, live-updates, een meldingeninfrastructuur
• Complexe integraties (ERP, bank-API's, medische systemen, alles met een compliancelaag)
• Native mobiele apps
• Zware maatwerklogica: matchingalgoritmen, planningsengines, prijscalculators met veel randgevallen

Niets hiervan betekent "onmogelijk". Het betekent dat we opdelen. Fase één levert het riskantste, meest waardevolle stuk in een paar weken op. Elke volgende fase wordt pas geprijsd als de vorige live staat en je er iets van leert. Je betaalt nooit vooruit voor maand vier op basis van gissingen uit maand nul.

Past je idee in de variant met smalle scope? Het MVP-aanbod staat hier, met een beschrijving van het proces.

De grootste kostenhefboom: bouw voor je riskantste aanname

Founders richten zich vaak op het onderhandelen over het tarief. Een grotere hefboom kan zijn wat je als eerste besluit te bouwen: het kleinste ding dat je riskantste aanname test.

Bij veel producten is de aanname die je vroeg wilt testen niet "kan dit gebouwd worden", maar "gaat iemand ervoor betalen". Dat kun je vaak testen voordat je een volledig product financiert:

• Landingspagina + echte betaalknop: beschrijf het product en neem echte voorbestellingen of aanbetalingen aan. Als bezoekers niet op "betalen" klikken, is dat een reden om je af te vragen of een volledige app al financiering verdient. Zo'n pagina staat in een paar dagen live voor de instapprijs van een landingspagina.
• MVP met één flow: de ene kernactie, echt uitgewerkt, met echte betalingen. Dit is het terrein vanaf 5 000 €.
• Volledig platform: rollen, beheer, integraties, mobiel. Pas verantwoord nadat de kernflow betalende gebruikers heeft, want dan bouw je voor gemeten vraag en niet voor ingebeelde vraag.

De duurste fout die ik het vaakst zie: meteen naar niveau drie springen. Een half jaar en een serieus budget later leert de founder iets wat een landingspaginatest van twee weken voor een fractie van het geld had laten zien. Scope schrappen is geen genoegen nemen met minder, het is dezelfde kennis sneller en goedkoper kopen.

Een nuttige oefening voordat je een offerte aanvraagt: schrijf de ene zin op die je van een klant wilt horen ("ja, hier betaal ik X € per maand voor"). Vraag je dan af wat de minimale bouw is waarna een echte klant die zin kan zeggen. Dat is je MVP. Al het andere is fase twee.

AI-prototypes: goedkoop te starten, duur om productieklaar te maken

In 2026 haal je in één middag een prototype uit Lovable, v0 of Bolt dat werkt zoals het eruitziet, soms voor de prijs van een abonnement. Dat heeft de beginfase echt veranderd, en het verdient een eerlijke beoordeling in plaats van hype of afwijzing.

Wanneer een AI-prototype genoeg is:

• Investeerders of eerste klanten visueel laten zien wat je bedoelt
• Testen of een UI-concept klopt voordat je je eraan verbindt
• Interne demo's en klikbare mockups
• Interesse valideren vóór je echt gaat bouwen

Waar het meestal vastloopt:

• Echte gebruikers. Prototypes die werken voor één beleefde tester, vallen om bij gelijktijdige gebruikers, foute invoer en randgevallen waar niemand in de prompts om had gevraagd.
• Betalingen. Echt geld ontvangen betekent webhooks, afhandeling van mislukte betalingen, terugbetalingen en belasting. Dat stuk slaan AI-tools over, omdat de happy path in een demo ook zonder werkt.
• Beveiliging en data. Inloggen dat accounts echt beschermt, rechten die de toegang echt beperken, een database die niet lekt. Gegenereerde code ziet er vaak goed uit en is het niet.
• Veranderingen. Bij de tiende iteratie op gegenereerde code stort het tempo in: niemand, ook de AI niet, begrijpt nog helemaal wat er staat.

De valkuil is niet dat je met een AI-prototype begint, dat is vaak slim. De valkuil is dat je het voor het product aanziet en de kloof pas ontdekt nadat je een lanceerdatum hebt aangekondigd. Heb je al een prototype dat je tot hier heeft gebracht maar niet verder komt? Precies die situatie behandelt AI-prototype naar productie: we behouden wat gevalideerd is en bouwen opnieuw wat echte gebruikers en echt geld moet kunnen dragen.

Reken het prototype in je budget tot de uitgaven voor validatie, niet voor bouw. Het helpt bij de vraag "is dit het bouwen waard". Om het product werkend te krijgen is een eigen scope en budget nodig.

Verborgen kosten die founders vergeten te begroten

De bouwprijs is niet de hele prijs. Deze kosten zijn meestal elk afzonderlijk bescheiden, maar ze na de lancering één voor één ontdekken kan van "5 000 €" een zure herinnering maken. Zet ze meteen in je spreadsheet:

• Hosting. Een typische vroege MVP draait goedkoop op moderne platforms, aanvankelijk vaak bijna gratis, maar het is een terugkerende post en hij groeit mee met het gebruik.
• Domein en e-mail. Het domein zelf is goedkoop. Professionele e-mail op je domein is een kleine maandelijkse kostenpost die routinematig wordt vergeten.
• Externe API's. Betalingen kosten een percentage van elke transactie. Kaarten, sms, e-mailverzending, AI-API's: alles wordt op gebruik gemeten. Bij MVP-volume is dat prima, maar ze moeten op de lijst staan, want ze schalen mee met succes.
• Onderhoud. Afhankelijkheden en beveiligingspatches moeten worden bijgewerkt en de eerste echte gebruikers kunnen problemen vinden die geen test heeft opgespoord. Een product is geen eenmalige aankoop, het vraagt blijvende aandacht.

Zo pak ik dat aan: de schriftelijke scope die je krijgt voordat je iets betaalt, bevat de verwachte lopende kosten, openlijk en in bedragen, en de accounts staan op jouw naam: hosting, domein, betaalprovider, alles. Infrastructuur en code zijn vanaf dag één van jou, dus van developer wisselen betekent niet dat je je product kwijtraakt. Na de lancering kies je: je onderhoudt het product zelf (het is jouw gedocumenteerde code) of je sluit een onderhoudsovereenkomst met een omschreven scope. De voorwaarden van beide opties liggen vooraf vast.

Vragen om te stellen voordat je iemand betaalt

Of je nu met mij praat of met iemand anders: deze vragen scheiden professionals van dure lessen:

1. "Wat zit er precies in de prijs, op papier?" Een scope die in een appje past, groeit uit in de factuur. Eis een schriftelijke lijst van wat wordt opgeleverd en, even belangrijk, wat niet.
2. "Vaste prijs of schatting?" Een "schatting" is een bedrag dat groeit. Vraag wie de overschrijding draagt als het werk langer duurt.
3. "Wanneer zie ik werkende software?" Wekelijkse demo's van het echte product, of een grote onthulling aan het eind? Bij grote onthullingen gaan budgetten dood.
4. "Van wie zijn de code en de accounts?" De repository, de hosting, het domein: op wiens naam? "Van ons, tot de laatste betaling" is een riem om je nek.
5. "Wat gebeurt er na de lancering?" Wat kost het oplossen van een bug? Wat is de reactietijd als er op zaterdag iets omvalt?
6. "Kan ik praten met iemand voor wie je iets hebt opgeleverd?" Een portfolio kun je opsieren. Een gesprek van een kwartier met een eerdere klant niet.

Irritatie of ontwijkende antwoorden op deze vragen zijn zelf al een waarschuwingssignaal.

Zo verloopt het proces met mij

Voor de transparantie: dit gebeurt er precies als we samenwerken. Het is de checklist hierboven, beantwoord:

1. Gratis gesprek van 20 minuten. Jij beschrijft het idee, ik zeg eerlijk of het in een MVP met smalle scope past of fasering nodig heeft, ook als het eerlijke antwoord is: "begin eerst met een landingspaginatest".
2. Vaste schriftelijke scope, prijs en planning. Voordat er geld beweegt, heb je een document met wat er wordt gebouwd, wat het kost en wanneer het klaar is. Staat iets niet in het document en wil je het wel, dan is het een geprijsde uitbreiding en geen verrassing.
3. Wekelijkse demo. Je ziet elke week het echte product werken, geen slides erover. Bijsturen gebeurt zolang het goedkoop is.
4. Alles is van jou. Code in jouw repository, infrastructuur op jouw accounts, vanaf het begin.
5. Antwoord meestal binnen 2 uur. Tijdens de bouw en erna. Je werkt met degene die de code schrijft: meer dan 12 jaar ervaring met webproducten, 150+ projecten, gevestigd in Warschau, founders uit de EU en daarbuiten.

Valideer de riskantste aanname voordat je het hele product financiert

Een MVP kan in 2026 kosten van 5 000 € tot zescijferige bedragen, en een groot deel van het verschil komt voort uit scope en werkwijze. (De volledige ladder van no-code in eigen beheer tot een enterpriseteam, met kostenfactoren en manieren om kosten te beheersen, vind je in het artikel kosten van webontwikkeling per budget.) Een verstandige aanpak is: definieer het kleinste project dat je riskantste aanname test, zet het live en gebruik de data van echte gebruikers om te beslissen wat in fase twee financiering waard is.

Wil je een echt bedrag voor jouw idee in plaats van een range? Plan het gratis gesprek van 20 minuten. Je gaat er weg met een concreet antwoord: een vaste offerte, een plan in fasen of een eerlijk "test het eerst goedkoper".