Praat met ons over uw proof of concept.
Een kennismaking van een half uur, vrijblijvend. Vertel ons welke aanname u eigenlijk wil toetsen — we denken mee, scherpen de vraag aan, en geven richting voor wat een PoC u zou opleveren.
Dienst · Web-ontwikkeling
Proof of concept (PoC) laten maken.
Een klein, snel prototype dat één technische aanname valideert vóór u een grote investering doet. Goedkoper dan een MVP, gerichter dan een pilot. Voor IT-besluiten waar het antwoord op "kán het eigenlijk wel?" eerst hard onderbouwd moet zijn.
Wat is een proof of concept.
Een proof of concept (PoC) is een lean prototype dat één specifieke aanname toetst: kunnen we deze data koppelen, leert dit model van onze data, haalt dit platform de performance bij ons volume? Het doel is niet een werkend product opleveren — het doel is met de minst mogelijke investering aantonen dat het idee technisch werkt vóór er groter geld in gaat. Een PoC is daarmee een investering in ríscoreductie, niet in eindproduct.
Daarmee is een PoC fundamenteel anders dan een MVP of een pilot. Een MVP is de kleinste versie van een product die u échte gebruikers laat ervaren — daar gaat het over markt- en gebruikersvalidatie. Een pilot toetst of het schaalt in een realistische productie-omgeving met echte klanten of operationele situaties. Een PoC daarentegen beantwoordt de kale ingenieursvraag: "kán dit?" — en niets meer. Voor veel besluiten over digitale transformatie, AI-adoptie of vendor-keuze is dat precies het signaal dat ontbreekt voordat een board-besluit verantwoord gemaakt kan worden.
De Nederlandse mid-market en enterprise zit vol met grote IT-besluiten die op gevoel worden genomen omdat er geen tijd of zin was om eerst hard te onderzoeken of het idee technisch klopt. Daar gaan jaarlijks miljoenen verloren aan projecten die op papier perfect waren maar in de praktijk strandden op een aanname die niemand had getest. Een goed gescopete PoC kost daar een fractie van en geeft uw stuurgroep iets concreets om mee te werken.
Wij bouwen al jaren PoC's voor organisaties die voor zo'n grote IT-keuze staan: een vendor-vergelijking, een AI-ambitie, een legacy-migratie, een architectuur-keuze. De pagina hieronder legt uit wat we precies leveren, wanneer een PoC echt zin heeft, en wat we bewust níet doen in een PoC-traject.
Drie typen proof of concept.
De meeste PoC-vragen vallen in één van deze drie categorieën. We adviseren in het kennismakingsgesprek welk type bij uw vraagstuk past — soms zit het antwoord al in een uurtje whiteboard zonder dat er gebouwd hoeft te worden.
Technische PoC
Voor wanneer de vraag puur engineering is. Werkt deze sensor in onze fabrieksomgeving? Kunnen we System X koppelen aan Y zonder dat de doorlooptijd ontspoort? Haalt onze architectuur de gewenste throughput onder realistische belasting? Aan het eind heeft u een werkende test-opstelling met meetwaarden, geen presentatie. Reproduceerbaar te draaien, met de scripts en configuratie erbij, zodat uw eigen team het kan natrekken of doortrekken.
IntegratiePerformanceHardware/IoTArchitectuur
AI/ML proof of concept
Voor vragen als "leert een model patronen uit ónze data?". We trainen op een sample van uw eigen data, valideren tegen een eerlijke baseline (vaak een simpele rule-based aanpak of het bestaande proces), en rapporteren accuracy, false-positive rate, en de aannames die we hebben moeten doen om er te komen. Geen demo met cherry-picked voorbeelden — een onderbouwd ja, nee, of "ja mits": kwaliteit van labels op orde, datavolume X, hertraining-cadens Y.
Model-haalbaarheidData-kwaliteitBaseline-vergelijkingBias-check
Vendor- of platform-vergelijking
U twijfelt tussen Snowflake en Databricks. Microsoft Fabric of native AWS. Eigen API-gateway of Kong. We zetten een vergelijkbare workload op beide platforms op, draaien dezelfde scenario's, en leveren een matrix met kosten-, performance- en operationele bevindingen — inclusief wat u alleen leert door het écht te draaien en niet uit de docs of een vendor-deck haalt. Bedoeld als beslis-input voor een board, een aanbestedings-traject, of een interne architectuur-keuze.
Side-by-sideTCO-indicatieOperationele fitLock-in-analyse
Wat u krijgt aan het einde.
Een PoC is pas waardevol als het bruikbare evidence oplevert voor een board, stuurgroep of architectuur-raad. Ons standaard-pakket bevat dus altijd zowel het werkende artefact als de uitleg eromheen.
- Een werkende PoC-demoEchte code of een echte test-opstelling — geen Figma-mockup of slide-deck. Reproduceerbaar te draaien, met instructies.
- Documentatie van leerpuntenWat werkte, wat niet, en waarom. Inclusief de aannames die we expliciet hebben moeten maken en de risico's die we onderweg hebben gevonden.
- Heldere aanbevelingDoorgaan, stoppen of aanpassen. Met onderbouwing. Een eerlijk "stoppen" is wat ons betreft net zo waardevol als een "doorgaan" — u heeft de kosten van een mislukt groot project bespaard.
- Code en configuratie als basis voor de vervolgstapDe PoC-code is geen wegwerp — relevante delen zijn herbruikbaar als startpunt voor een MVP of productieversie.
- Indicatie van vervolg-investeringEen eerste richting voor wat een MVP of productie-implementatie ongeveer aan effort zou kosten — onderbouwd vanuit wat de PoC heeft uitgewezen.
- Een werksessie met uw teamAan het eind nemen we de bevindingen samen door met uw architecten, product-owner en eventueel een stakeholder uit de business — zodat de conclusies écht landen waar de beslissing valt.
Wanneer een PoC zin heeft.
Niet elk software-vraagstuk vraagt om een PoC. Maar in deze patronen levert een paar weken vooronderzoek vaak vele factoren meer op aan vermeden risico of bespaarde kosten.
AI & ML
Model-haalbaarheid op eigen data
U overweegt voorspelmodellen, anomaliedetectie of NLP op uw eigen dataset, maar weet niet of de data signaal bevat. Een PoC traint op een steekproef en geeft eerlijk uitsluitsel — inclusief wat er aan datakwaliteit nog moet gebeuren.
Integratie
Koppeling met legacy of vendor
U weet niet of een specifiek systeem zich laat ontsluiten zonder de stabiliteit aan te tasten. Vooral relevant bij legacy-software vervangen en bij integraties met SaaS-vendors zonder volwassen API.
Performance
Schaalt het bij ons volume
Een leverancier zegt dat z'n platform 10k transacties per seconde kan. Op papier. Een PoC vertelt of het ook bij úw datavolumes, queries en piekpatronen overeind blijft — en wat de operationele kosten dan zijn.
Vendor-keuze
Build vs buy of vendor A vs B
Tussen twee platformen kiezen kan een PoC-vraag zijn. Lees ook ons artikel over de build vs buy beslissing — soms blijkt na een korte PoC dat een standaardpakket toch volstaat.
Architectuur
Microservices, event-driven of toch monoliet
Architectuur-keuzes zijn duur om terug te draaien. Een PoC kan met een realistisch slice valideren of een patroon werkt voor uw team-grootte, deployment-frequentie en use-case.
Migratie
Cloud-migratie of replatforming
De vraag is zelden "kan iets naar de cloud" maar "kan deze workload zonder downtime, met behoud van compliance, voor acceptabele kosten". Een PoC met een geïsoleerd deel van het landschap geeft daar concreet antwoord op.
Hardware & IoT
Sensoren of edge-hardware in uw omgeving
Spec-sheets klinken altijd mooi. Pas wanneer de sensor of het edge-device daadwerkelijk in uw fabriek, voertuig of installatie zit weet u of het signaal stabiel is, of de connectiviteit aanvaardbaar blijft, en welke storingen u in de praktijk gaat tegenkomen.
Compliance
Privacy- of regelgeving-aspect
Soms is de vraag of een idee überhaupt mág binnen AVG, AI Act of sectorspecifieke regelgeving. Een korte PoC, gekoppeld aan een privacy- of compliance-toets, kan voorkomen dat u na maanden ontwikkeling alsnog tegen een onoverkomelijk juridisch obstakel oploopt.
Nog niet zeker over een groot traject?
Test je idee eerst — werkend prototype in 1 dag
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Hoe een PoC-traject loopt.
1
Kennismaking en vraag aanscherpen
Een gesprek waarin we de aanname destilleren die u eigenlijk wil toetsen. Vaak zit hier al de helft van de waarde: een goed gestelde PoC-vraag is veel scherper dan "kunnen we hier eens iets mee?". Soms blijkt na een uur dat een PoC niet eens nodig is omdat het antwoord al bekend is uit literatuur of bestaande implementaties.
2
Scope-document en succes-criteria
We leggen vast: welke aanname toetsen we, welke meetwaarden vertellen ons of het slaagt, welke data of toegang hebben we nodig van uw team. Dit is bewust kort — een PoC ontspoort vrijwel altijd doordat scope uitloopt, niet door technische problemen.
3
Bouwen in een paar korte sprints
Lean engineering: minste code die de vraag kan beantwoorden, geen polish, geen "we maken het meteen productie-ready". Wekelijkse check-in met uw architect of product-owner zodat verrassingen vroeg op tafel komen.
4
Evaluatie en aanbeveling
We presenteren de bevindingen aan uw team. Niet alleen "het werkt" of "het werkt niet" — ook de aannames waaronder, de gevonden risico's, en de geschatte effort voor een volgende stap. Schriftelijk en mondeling, zodat het stuur-gesprek hierna scherp gevoerd kan worden.
Wat we bewust níet doen in een PoC.
Een PoC is alleen waardevol als 'ie klein blijft. Dit zijn de zaken die we expliciet buiten scope houden — niet uit luiheid, maar omdat ze de PoC zouden ombouwen tot iets anders.
Niet in scope
Productie-niveau security
Een PoC krijgt basale security maar geen volledige hardening, geen pen-test, geen SOC2-niveau compliance. Dat hoort bij de MVP of productie-versie waar échte gebruikers data invoeren — niet bij een test-opstelling in een afgeschermd lab.
Niet in scope
Schaalbaarheid ver boven testvolume
We valideren of het werkt bij een realistische werklast, niet bij de piek-piek-belasting van een eindstadium-implementatie. Dat overslaan is bewust — anders bouwt u een mini-productieplatform onder de noemer PoC.
Niet in scope
Volledige UX of design
Een PoC heeft net genoeg interface om de aanname te kunnen toetsen. Geen design-systeem, geen brand-werk, geen UX-onderzoek met eindgebruikers. Dat verschuift naar het MVP-traject waar interactie wél onderdeel van de vraag is.
Niet in scope
Documentatie voor eindgebruikers
De PoC krijgt technische documentatie voor architecten en uw IT-team, niet handleidingen voor business-gebruikers. Als de PoC succesvol is en u rolt door naar MVP, dan komt eindgebruikers-documentatie in dat traject.
Niet in scope
Beheer en SLA
Een PoC draait in een staging- of sandbox-omgeving zonder SLA. Geen 24/7-monitoring, geen incident-response, geen backup-strategie op productie-niveau. Dat zou een veelvoud van de PoC-investering kosten en levert niets extra's op aan beslis-input.
Niet in scope
Volledige integratie-breedte
We koppelen het minimum aan systemen dat nodig is om de vraag te beantwoorden — niet ineens uw hele applicatielandschap. Een integratie-PoC die "alles met alles" probeert te verbinden is geen PoC meer.
Veelgestelde vragen.
De vragen die we meestal krijgen in het eerste PoC-gesprek.
Wat is het verschil tussen een PoC, een MVP en een pilot?
Een PoC (proof of concept) toetst "kán het?" — puur technische haalbaarheid. Een MVP (minimum viable product) toetst "wíllen mensen het?" — de kleinst mogelijke werkende versie van een product die u aan echte gebruikers durft te tonen. Een pilot toetst "schaalt het?" — een beperkte productie-implementatie bij een afgebakende klantengroep of locatie. De drie volgen elkaar vaak op, maar slaan elkaar soms ook over: voor een puur infrastructureel besluit kan een PoC genoeg zijn zonder ooit een MVP te bouwen.
Wanneer heeft een PoC zin en wanneer niet?
Een PoC heeft zin als er een concrete onzekerheid is die u nu niet kunt beslechten via desk-research of een gesprek met een architect. Vooral bij AI-modellen op eigen data, performance bij grote volumes, integratie met legacy, en vendor-keuzes. Een PoC heeft géén zin als de onzekerheid niet technisch maar commercieel is (dan eerder een MVP), als het probleem al elders aantoonbaar opgelost is, of als de scope zo breed wordt dat het feitelijk al een MVP wordt.
Wat als de PoC mislukt — is dat verspild geld?
Een mislukte PoC is juist één van de waardevolste uitkomsten: u heeft voor een fractie van de kosten van een mislukt groot project geleerd dat een richting niet werkt, vaak inclusief de specifieke redenen. We hebben opdrachtgevers die uit een "nee" van een PoC tonnen aan vermeden investering hebben gehaald. We rapporteren falen daarom net zo zorgvuldig als succes — inclusief wat ervoor nodig zou zijn om het alsnog mogelijk te maken.
Wat bepaalt de kosten van een PoC?
Drie dingen: hoe scherp de vraag al is bij de start, hoe toegankelijk de data of systemen zijn die nodig zijn voor de test, en hoe diep de validatie moet gaan. Een AI-haalbaarheids-PoC op schone data is veel lichter dan een PoC die eerst data uit drie legacy-systemen moet ontsluiten. We geven na het eerste gesprek een onderbouwde indicatie en bewaken het sprint-budget strak — een PoC die uitloopt is zelden meer een PoC.
Hoe lang duurt een PoC-traject?
Een goed gescopete PoC is een traject van een beperkt aantal sprints — bewust kort. Doel is dat u snel een onderbouwd antwoord heeft voor uw besluitvorming, niet dat we een mooi product opleveren. Als blijkt dat de scope te groot wordt, splitsen we liever in twee kleinere PoC's of stappen we over naar een MVP-traject.
Wat doen jullie expliciet NIET in een PoC?
Geen productie-niveau security en compliance (die hoort bij MVP/productie). Geen volledige UX of design — alleen wat nodig is om de vraag te beantwoorden. Geen documentatie voor eindgebruikers. Geen beheer of SLA. Geen schaalbaarheidsoptimalisatie ver buiten het testvolume. Dat klinkt als "veel niet", maar dat is precies waarom een PoC een PoC is: door deze dingen bewust over te slaan houden we het traject klein en focused.
Wie zijn typische opdrachtgevers voor een PoC?
CTO's, CIO's en innovatie-managers in mid-market en enterprise. Business-units die voor een board een investering moeten verantwoorden en niet met handen-in-de-lucht willen aankomen. Organisaties die voor een grote keuze staan zoals enterprise software laten ontwikkelen, een ERP-vervanging, of een eerste serieuze stap met AI. Ook IT-afdelingen die intern willen onderzoeken of een idee uit de business technisch haalbaar is voordat ze het commitment geven.
Wat gebeurt er na een succesvolle PoC?
Meestal een MVP of een directe productie-implementatie, afhankelijk van wat de PoC heeft uitgewezen. We kunnen die vervolgstap doen, maar zijn niet verplicht — de PoC-code en documentatie is van u en kunt u ook door uw eigen team of een andere partij laten doortrekken. Indicatieve effort en aandachtspunten voor het vervolg krijgt u mee in onze eindrapportage. Lees ook onze kennisbank over wat maatwerksoftware kost als u zich oriënteert op het bredere prijskader.