PoC vs Prototype vs MVP: welke heb je echt nodig?

Plan je een nieuw webproduct? Dan ben je vast al drie termen tegengekomen die vaak door elkaar worden gebruikt: PoC vs prototype vs MVP. Ze klinken hetzelfde, en veel artikelen behandelen ze ook alsof het synoniemen zijn met andere labels. Dat zijn ze niet.

Elk antwoordt op een fundamenteel andere vraag over je project. Een proof of concept vraagt: 'kunnen we dit bouwen?' Een prototype vraagt: 'hoe moet het eruitzien en aanvoelen?' Een MVP vraagt: 'gaan mensen hier echt voor betalen?' De verkeerde keuze maken — of meteen doorschieten naar development — is een van de duurste fouten die ik bedrijven zie maken.

Deze gids legt uit wat elke aanpak echt inhoudt, wanneer je voor de ene of de andere kiest, en wat je aan budget moet rekenen. Of je nu een startup-oprichter bent die een nieuw idee test of een ondernemer die een bedrijfswebsite of webportaal plant: dit helpt je om een slimmere eerste zet te doen.

Wat de meeste mensen missen: PoC's, prototypes en MVP's zijn geen concurrerende opties. Het zijn verschillende fases waarin je het risico van een productidee verkleint. Elke fase haalt een specifiek soort onzekerheid weg voordat je serieus geld steekt in volledige ontwikkeling.

Zie het zo:

• PoC elimineert technisch risico — kan het kernidee überhaupt werken?
• Prototype elimineert ontwerp­risico — gaan gebruikers het begrijpen en prettig vinden?
• MVP elimineert marktrisico — is er echte vraag naar dit product?

Niet elk project heeft alle drie nodig. Een eenvoudige landingspagina hoeft geen proof of concept te krijgen. Een complex webportaal met maatwerkintegraties waarschijnlijk wel. De truc is weten welke risico's voor jouw situatie het grootst zijn en die als eerste aanpakken.

Volgens onderzoek van CB Insights mislukt 42% van de startups omdat ze producten bouwen waar niemand op zit te wachten. Dat is een marktrisicoprobleem — en precies waarvoor een MVP is bedoeld, voordat je je budget erdoorheen jaagt.

Een proof of concept is de eenvoudigste test die je kunt uitvoeren om één vraag te beantwoorden: is dit technisch haalbaar?

Het is geen product. Het ziet er niet mooi uit. Het is niet iets wat je aan klanten laat zien. Een PoC is een intern experiment — vaak maar een paar dagen werk — dat valideert of een specifieke technische aanpak overeind blijft onder echte omstandigheden.

Stel dat je een webportaal wilt bouwen dat realtime voorraadgegevens uit drie verschillende magazijnsystemen ophaalt. Voordat je maanden aan ontwikkeling besteedt, bouw je een PoC die met één van die systemen verbindt en bevestigt dat de datatransfer werkt zoals verwacht. Geen UI, geen branding, geen user flows — alleen het bewijs dat het lastigste technische stuk oplosbaar is.

Wanneer een PoC zinvol is

• Je werkt met onbekende technologie of API's van derden
• Het idee hangt af van een specifieke technische functie die nog niet getest is
• Stakeholders willen bewijs zien dat iets mogelijk is voordat ze budget vrijmaken
• Je weegt af of je iets op maat bouwt of een kant-en-klare oplossing gebruikt

Wat een PoC oplevert

Een werkende (maar ruwe) demonstratie dat het technische kernidee houdbaar is. Meestal vastgelegd met bevindingen en aanbevelingen voor de volgende stappen. Zoals het Product Development Body of Knowledge-framework aangeeft, zijn PoC's het meest effectief als ze beperkt blijven tot één technische hypothese in plaats van meerdere aannames tegelijk te willen valideren.

Typische doorlooptijd: 1-3 weken

Wie het ziet: intern team, technisch leads, beslissers. Geen klanten.

Een prototype beantwoordt een heel andere vraag: hoe gaat dit ding eruitzien en voelen in gebruik?

In tegenstelling tot een PoC is een prototype visueel. Het simuleert de gebruikerservaring — schermen, navigatie, interacties — zonder werkende backend. Zie het als een gedetailleerde maquette van een gebouw. Je kunt door de kamers lopen en een gevoel krijgen voor de ruimte, maar het sanitair is nog niet aangesloten.

Prototypes lopen uiteen van low-fidelity (wireframes, papieren schetsen) tot high-fidelity (pixelnauwkeurige klikbare mockups in Figma of vergelijkbare tools). Het detailniveau hangt af van wat je wilt leren.

Wanneer een prototype zinvol is

• Je wilt de gebruikerservaring valideren voordat je code schrijft
• Investeerders of stakeholders willen zien hoe het product eruit gaat zien
• Je twijfelt tussen meerdere ontwerprichtingen
• Je hebt usability-tests nodig om wrijvingspunten vroeg te vinden

Prototyping is bijzonder waardevol voor UX/UI-design-beslissingen. Onderzoek van de Nielsen Norman Group bevestigt dat testen met prototypes usability-problemen vindt voor een fractie van de kosten van het oplossen ervan in productiecode. Ik heb teams meegemaakt die deze stap oversloegen en direct gingen ontwikkelen, om er drie maanden later achter te komen dat de navigatie niet logisch is of dat belangrijke user flows verwarrend zijn. Die problemen oplossen in code is vijf tot tien keer duurder dan in een prototype. Voordat je serieus aan prototyping begint, zorgt een helder website-designbriefing ervoor dat de ontwerprichting aansluit bij de bedrijfsdoelen en stakeholderverwachtingen.

Wat een prototype oplevert

Een klikbare, visuele weergave van je product waarmee echte gebruikers kunnen interacteren en feedback geven.

Typische doorlooptijd: 2-6 weken

Wie het ziet: intern team, stakeholders, investeerders en idealiter een kleine groep doelgebruikers voor tests.

Een MVP — minimum viable product — is waar het echt wordt. Het is een werkend product met net genoeg functies om vroege gebruikers te bedienen en te testen of er echte marktvraag is.

Het sleutelwoord hier is 'viable' (levensvatbaar). Een MVP is geen halve, bug-doorspekte versie. Het is een bewust afgeschaalde versie die één of twee dingen goed doet. Alles wat niet essentieel is, wordt geschrapt. Het doel is niet perfectie; het doel is leren.

Eric Ries, die de term populair maakte in The Lean Startup, beschreef het als de versie van een nieuw product waarmee een team de meeste gevalideerde kennis kan verzamelen met de minste inspanning. Die definitie houdt nog altijd stand.

Wanneer een MVP zinvol is

• Je hebt haalbaarheid (PoC) en bruikbaarheid (prototype) gevalideerd, en wilt nu marktvraag testen
• Je wilt echte gebruikersfeedback voordat je je vastlegt op een volledige productroadmap
• Je wilt investeerders aantrekken met aantoonbare tractie, niet alleen een idee
• Time-to-market telt en je kunt geen 12-maanden ontwikkelcyclus permitteren

Ongeveer 72% van de startups gebruikt nu een MVP-aanpak, en met goede reden. Bedrijven die aannames valideren met een MVP hebben ongeveer 20% meer kans om de eerste vijf jaar te overleven.

Wat een MVP oplevert

Een live, functioneel product met kernfuncties waarop echte gebruikers zich kunnen aanmelden, dat ze kunnen gebruiken en waarop ze feedback geven. Of het nu gaat om een landingspagina met een centrale transactieflow of een volledige bedrijfswebsite met essentiële functies — de MVP draait om echte waarde leveren aan early adopters.

Typische doorlooptijd: 6-16 weken

Wie het ziet: echte gebruikers, early adopters, potentiële investeerders, de markt.

Hier is de helderste manier om te zien hoe deze drie aanpakken verschillen:

Let op de volgorde: technische validatie eerst, dan ontwerp­validatie, dan marktvalidatie. Niet altijd zijn alle drie nodig, maar je moet nooit een stap overslaan die relevant is voor het grootste risico van je project.

Met abstracte definities kom je maar beperkt verder. Laten we kijken hoe echte bedrijven deze aanpakken hebben ingezet.

Dropbox (MVP): voordat er één regel backendcode geschreven was, maakte Dropbox-oprichter Drew Houston een video van drie minuten waarin hij liet zien hoe het product zou werken. Die video wás de MVP. Hij ging viraal en het aantal aanmeldingen sprong van 5.000 naar 75.000 in één nacht. Geen werkend product — alleen een demonstratie die enorme marktvraag valideerde.

Zappos (MVP): Nick Swinmurn bouwde geen e-commerce-platform. Hij plaatste foto's van schoenen uit lokale winkels op een eenvoudige website. Als iemand bestelde, ging hij naar de winkel, kocht de schoenen en verstuurde ze. Deze MVP zonder voorraad bewees dat mensen schoenen online wilden kopen — een concept waar in 1999 velen aan twijfelden.

Airbnb (PoC + MVP): Brian Chesky en Joe Gebbia begonnen met het verhuren van luchtbedden in hun eigen appartement tijdens een designconferentie. Dat was eigenlijk een proof of concept — testen of vreemden zouden betalen om bij iemand thuis te logeren. Eenmaal gevalideerd bouwden ze een eenvoudige website (de MVP) en breidden ze uit.

Valt het patroon op? Geen van deze bedrijven begon met een afgewerkt product. Ze identificeerden hun grootste risico, testten dat met de goedkoopst mogelijke aanpak en investeerden pas meer toen de data dat ondersteunden.

Voorbeeld webproject: stel dat je een klantgerichte landingspagina bouwt met een dynamische prijscalculator. De calculator haalt data uit je ERP-systeem. Je zou een PoC kunnen draaien om de ERP-integratie te testen, een prototype maken van de calculator-UI om er zeker van te zijn dat hij intuïtief is, en daarna een MVP lanceren met de calculator als kernfunctie.

Budget is altijd de olifant in de kamer, dus laten we het over cijfers hebben. Deze bandbreedtes komen uit tientallen webprojecten die ik heb gezien, geen hypothetische gemiddelden.

Proof of Concept: $2.000-$15.000 afhankelijk van complexiteit. Een eenvoudige API-integratietest kost een ontwikkelaar misschien een paar dagen. Een complexe datapijplijn over meerdere systemen testen kan twee tot drie weken kosten met een klein team.

Prototype: $5.000-$30.000. Een set low-fidelity-wireframes zit aan de onderkant. Een volledig interactief, high-fidelity klikbaar prototype mét gebruikerstests zit aan de bovenkant. De meeste webprojecten landen rond de $8.000-$15.000 voor een degelijk prototype.

MVP: $15.000-$150.000+. Hier wordt de range breed omdat de scope enorm verschilt. Een eenvoudige web-app-MVP met één of twee kernfuncties en basis-UI lukt voor $15.000-$40.000 in zes tot tien weken. Een complexere SaaS-MVP met multi-tenant-dashboards en integraties met derden? Reken op $55.000-$140.000 en acht tot veertien weken.

Eén cijfer is het vermelden waard: een Gartner-rapport uit 2024 wees uit dat bedrijven met low-codeplatforms hun MVP's 50-70% sneller leveren met kostenbesparingen van 50-65% vergeleken met traditionele ontwikkeling. Dat betekent niet dat low-code altijd de juiste keuze is, maar het laat zien hoeveel het tooling­landschap is verschoven.

De echte kostenbesparing komt voort uit op het juiste moment de juiste aanpak kiezen. Een volledige MVP bouwen terwijl je de technische kernaanname niet hebt gevalideerd? Zo verdampen budgetten met zes nullen. Zoals de gids van Smashing Magazine over lean UX uitlegt, helpen lean validatiemethoden — of het nu PoC, prototype of MVP is — teams om geen functies te bouwen waar niemand op zit te wachten.

Hier is het praktische framework dat ik gebruik bij klanten die niet weten waar ze moeten beginnen:

Begin met een PoC als:

• Je idee leunt op technologie die je nog niet hebt getest
• Je haalbaarheid moet bewijzen om interne steun of financiering te krijgen
• Er één kritieke technische afhankelijkheid is die het project kan maken of breken
• Je integreert met legacy­systemen of platforms van derden met onzekere API's

Begin met een prototype als:

• De technologie eenvoudig is, maar de gebruikerservaring complex
• Je meerdere stakeholders hebt met verschillende visies op het product
• Gebruikerstests essentieel zijn voordat je ontwikkelresources inzet
• Je een bestaand product herontwerpt en de nieuwe richting wilt valideren

Begin met een MVP als:

• Het concept (technisch én qua UX) bewezen is, maar de marktvraag onzeker
• Je zo snel mogelijk omzet of tractie wilt genereren
• Je echte gebruikersdata nodig hebt om je productroadmap te sturen
• Investeerders concrete gebruiks­statistieken willen zien, geen mockups

Gebruik ze in volgorde als:

• Je project hoge belangen en een hoog budget heeft
• Je een onbekende markt betreedt met onbewezen technologie
• De kosten van mislukken hoog genoeg zijn om gefaseerde validatie te rechtvaardigen

De meeste webprojecten die we bij Vezert doen, hebben niet alle drie nodig. Een redesign van een bedrijfswebsite kan direct naar prototyping. Een complex webportaal met realtime datafeeds heeft eerst een PoC nodig. Het juiste antwoord hangt af van waar je grootste onzekerheid zit. Voor bedrijfssite-projecten die van prototype naar build gaan, voorkomt vroeg nadenken over websitestructuur en informatiearchitectuur dure herstructurering zodra de ontwikkeling al loopt.

Na tientallen productlanceringen zie ik steeds dezelfde patronen:

Alles een MVP noemen. Een landingspagina met een e-mailformulier is geen MVP — dat is een smoke test. Een MVP heeft genoeg functionaliteit om gebruikers de kernwaarde te laten ervaren. Iets een MVP noemen terwijl het eigenlijk een prototype is (of minder), wekt vals vertrouwen.

De PoC overslaan bij technisch risicovolle projecten. Ik heb teams vier maanden zien werken aan een MVP, om er dan achter te komen dat de kernintegratie niet betrouwbaar werkt op schaal. Een PoC van twee weken had dat opgevangen.

Het prototype te ver doorontwikkelen. Het doel van een prototype is snelheid en leren, geen perfectie. Als je prototype drie maanden kost en er productie­klaar uitziet, heb je te veel uitgegeven. High-fidelity is prima; productiekwaliteit is overkill.

Functies bouwen waar niemand om vraagt. Dit is de klassieke MVP-val. Je voegt 'nog één functie' toe, totdat het minimum allang niet meer minimaal is. Zeven van de tien digitale producten falen binnen twaalf maanden, en feature creep is daar een grote bijdrager aan.

De feedbackloop negeren. Het hele punt van deze validatiefases is leren. Als je een prototype bouwt maar nooit met echte gebruikers test, of een MVP lanceert maar niet bijhoudt hoe mensen het gebruiken, heb je de moeite verspild.

Het verschil tussen PoC vs prototype vs MVP begrijpen, gaat niet alleen over terminologie — het is een framework om slimmere investeringskeuzes te maken voor je webproduct.

Een PoC vertelt je of de motor werkt. Een prototype vertelt je of mensen de auto kunnen besturen. Een MVP vertelt je of er iemand is die hem wil kopen. Elk bespaart je een ander soort dure verrassing.

De beste projecten waar ik aan heb gewerkt, begonnen met een helder beeld van het grootste risico en pakten dat aan met de goedkoopst mogelijke test. Die discipline — eerst testen, dan bouwen — onderscheidt producten die slagen van producten die hun budget verbranden en stilvallen.

Welke fase je ook in zit, het doel blijft hetzelfde: onzekerheid verkleinen voordat je investering opschaalt. Of je nu een proof of concept nodig hebt voor een complex webportaal, een prototype voor een nieuwe UX-richting, of een MVP om marktvraag te valideren — de juiste validatieaanpak bespaart tijd, geld en frustratie. Bekijk ons portfolio om te zien hoe we klanten hebben geholpen bij de PoC-vs-prototype-vs-MVP-keuze, of neem contact op om je project te bespreken.