Wat is een proof of concept (PoC)?

Een goed idee klinkt in de vergaderzaal altijd overtuigend. Of het ook echt werkt, weet je pas als je het bouwt. Toch stromen er dagelijks budgetten naar projecten die maandenlang op papier worden uitgewerkt, om vervolgens in de praktijk vast te lopen op iets wat je vooraf had kunnen weten.

Een proof of concept voorkomt precies dat. In dit artikel lees je wat een proof of concept is, wanneer je er wel en juist niet een inzet, en hoe het verschilt van een prototype en een MVP. En hoe wij haalbaarheid bewijzen met iets dat draait, niet met een slidedeck.

Een proof of concept (PoC) is een kleine, gerichte test die aantoont of een idee technisch en praktisch haalbaar is. Je bouwt niet het volledige product, maar precies genoeg om één cruciale aanname te bewijzen of te ontkrachten. Het doel is niet iets moois opleveren, maar zekerheid krijgen voordat je fors investeert.

Je komt de term ook tegen als PoC of POC, en soms als proof of principle. Dat laatste betekent in de praktijk hetzelfde: bewijzen dat het onderliggende principe werkt. Waar het om draait is de kernvraag. Een proof of concept beantwoordt “kan dit überhaupt?”, niet “hoe ziet het eruit?” of “willen gebruikers dit?”.

Je zet een proof of concept in om risico weg te nemen. Voordat je een groot budget vrijmaakt, wil je weten of het fundament klopt. Denk aan een koppeling met een systeem waarvan de documentatie rammelt, een AI-model dat op jouw data moet presteren, of een integratie tussen twee platformen die officieel niet samenwerken. Dat zijn de momenten waarop een PoC zijn geld terugverdient.

Een goede PoC beantwoordt vragen als:

• Kunnen we deze twee systemen betrouwbaar aan elkaar knopen?
• Presteert dit algoritme goed genoeg op onze eigen data?
• Is de doorlooptijd van dit proces technisch haalbaar binnen onze eisen?

Maar niet elk idee heeft een proof of concept nodig. Dat is het eerlijke deel van het verhaal. Bouw je iets met bewezen techniek en een voorspelbaar pad, dan is een PoC verspilde tijd. Je toont dan iets aan wat allang vaststaat. Een proof of concept hoort thuis waar echte onzekerheid zit, niet als verplicht vinkje in elk projectplan. Wie standaard een PoC inplant voor alles, verwart proces met vooruitgang.

De vuistregel: hoe groter het risico en hoe duurder de vergissing, hoe waardevoller de test vooraf.

Deze drie termen worden vaak door elkaar gehaald, terwijl ze elk een andere vraag beantwoorden. Kort samengevat:

Proof of concept: beantwoordt de kernvraag “Kan het?”. Het doel is haalbaarheid bewijzen, gericht op een intern, technisch publiek. Qua volledigheid gaat het om één aanname die je test.

Prototype: beantwoordt de kernvraag “Hoe voelt het?”. Het doel is ervaring en interactie tonen, gericht op intern publiek en stakeholders. Qua volledigheid is het een klikbare schets.

MVP: beantwoordt de kernvraag “Willen mensen het?”. Het doel is waarde valideren in de markt, gericht op echte gebruikers. Qua volledigheid is het een werkend minimumproduct.

Een proof of concept richt zich op technische en praktische haalbaarheid. Een prototype laat zien hoe iets eruitziet en aanvoelt, vaak klikbaar maar zonder echte werking eronder. Een MVP (minimum viable product) is het eerste échte product dat je aan gebruikers geeft, met net genoeg functionaliteit om te toetsen of er vraag naar is.

In de logische volgorde komt de proof of concept meestal eerst: eerst bewijzen dát het kan, dan hoe het werkt en of de markt erom vraagt. Wil je dieper in het verschil tussen PoC en MVP duiken? Dat is een onderwerp op zich, dat we in een apart artikel uitwerken. Hier houden we de MVP-uitleg bewust kort.

Een sterke proof of concept is klein en scherp. Hij toetst één vraag, met een vooraf afgesproken succescriterium dat je kunt meten. Geen open experiment waarvan je achteraf mag interpreteren of het “wel aardig” ging, maar een heldere uitkomst: gehaald of niet gehaald.

Drie kenmerken maken het verschil tussen een nuttige PoC en een dure hobby:

• Eén toetsvraag. Je test de meest risicovolle aanname, niet vijf dingen tegelijk. Focus houdt de test klein en het antwoord helder.
• Een meetbaar succescriterium. Bepaal vooraf wat “geslaagd” betekent. Bijvoorbeeld: de koppeling verwerkt duizend records per minuut, of het model haalt minimaal 90 procent nauwkeurigheid.
• Zo klein mogelijk. Bouw alleen wat nodig is om de vraag te beantwoorden. Alles daarbuiten is afleiding en kosten.

Een goede proof of concept levert dus geen product op, maar een beslissing. Je weet daarna of je doorgaat, bijstuurt of stopt. Dat is de winst.

Een PoC opzetten hoeft geen zware exercitie te zijn. Het proces past in vijf stappen:

1. Formuleer de kernvraag. Wat is de grootste onzekerheid in je idee? Benoem de aanname die, als hij niet klopt, het hele project onderuithaalt. Die aanname test je.

2. Bepaal het succescriterium. Leg vooraf vast wanneer de test geslaagd is. Maak het meetbaar en concreet, zodat de uitkomst niet voor discussie vatbaar is.

3. Bouw het kleinst mogelijke bewijs. Bouw precies genoeg om de vraag te beantwoorden. Geen nette interface, geen randfunctionaliteit. Alleen de kern.

4. Meet de uitkomst. Draai de test en leg de resultaten naast je criterium. Werkt het? Werkt het niet? Waar zaten de verrassingen?

5. Neem een beslissing. Ga door, stuur bij of stop. Een proof of concept die leidt tot “we stoppen ermee” is geen mislukking, maar een goedkope les die een dure vergissing voorkwam.

In softwareontwikkeling is de proof of concept een van de nuttigste instrumenten die er zijn, en tegelijk een van de meest verwarde. Het onderscheid dat telt: een PoC bewijst haalbaarheid, een maatwerktraject bouwt het echte product. Ze horen niet op één hoop.

Bij software gaat een PoC vaak over de vraag of een bepaalde technische aanpak werkt binnen jouw omgeving. Kan onze applicatie realtime data uit dat verouderde ERP-systeem trekken? Werkt deze AI-integratie op onze eigen bedrijfsdata, of alleen in de demo van de leverancier? Presteert deze architectuur onder de belasting die wij verwachten?

De valkuil is dat een geslaagde PoC de illusie wekt dat het product zo goed als af is. Dat is het niet. Een proof of concept is bewust ruw: geen beveiliging op orde, geen schaalbaarheid, geen nette code. Hij bewijst het principe en wordt daarna weggegooid of herbouwd. Wie een PoC rechtstreeks in productie duwt, bouwt technische schuld in vanaf dag één. Meer over wanneer je voor een bouwtraject kiest, lees je in wat is maatwerk software.

Waar veel bureaus een proof of concept presenteren als bureaucratische fase vol documenten en overleg, doen wij het anders. Haalbaarheid bewijzen komt bij ons neer op iets dat draait, al in sprint 1. Geen slidedeck met aannames, maar een werkend prototype dat de kernvraag beantwoordt.

Dat past bij onze filosofie: innovatie is pas geslaagd als het geadopteerd wordt. Techniek is het middel, menselijke adoptie is het doel. Een PoC die alleen op papier klopt, brengt je niets. Een PoC die je kunt aanraken, gebruiken en testen, geeft je een echte beslissing. Wij starten daarom niet met vergaderen, maar met valideren. Die aanpak noemen we de Troop Takeoff, waarmee we van abstractie naar actie gaan.

En ja, we zijn er eerlijk over: een proof of concept is goedkoop vergeleken met een misgelopen project, maar niet gratis. Het kost tijd en aandacht van senior mensen. De opbrengst is zekerheid: je weet of je idee werkt voordat je het grote budget vrijmaakt. Werkt het, dan hebben we meteen een fundament waarop we kunnen doorbouwen naar een volwaardig product. Hoe zo’n traject verloopt, zie je in onze werkwijze. Wil je na een geslaagde PoC doorpakken? Dan bouwen we het echte product, zoals we beschrijven op maatwerk software laten maken.