Je hebt een idee. Een stukje software dat een concreet probleem in je bedrijf zou oplossen, een lastige taak zou automatiseren, twee systemen zou integreren die niet met elkaar communiceren, of een portaal zou bouwen waar je klanten al lang om vragen. Op papier klinkt het volkomen logisch.
Maar je bent er niet helemaal zeker van of het zal werken zoals je je dat voorstelt. De integratie zou wel eens ingewikkelder kunnen zijn dan de documentatie van de leverancier doet vermoeden. De AI is misschien niet nauwkeurig genoeg voor je echte gegevens. De hele aanpak zou wel eens in duigen kunnen vallen zodra deze in aanraking komt met de chaotische realiteit van je bestaande systemen.
Je hebt dus een keuze. Je kunt het volledige budget inzetten en hopen dat het lukt. Je kunt maanden besteden aan workshops en analyses die wel documenten opleveren, maar geen werkende code. Of je kunt iets doen waarvan wij oprecht geloven dat het de slimste zet is die je kunt doen: twee weken de tijd nemen om erachter te komen.
Dat is wat een proof of concept is. En het zou wel eens het nuttigste kunnen zijn wat je dit jaar doet.
Wat je daadwerkelijk uit een POC haalt
Over twee weken is er werkende software die één specifieke vraag beantwoordt: zal dit idee in de praktijk standhouden?
Geen afgewerkt product. Geen strategiedocument van 40 pagina’s. Geen Figma-mockup. Echte code, die op echte gegevens draait en je laat zien of het meest risicovolle onderdeel van je project gaat werken.
Concreet krijg je het volgende mee:
Werkende code die de technische kern van je idee bevestigt (of weerlegt)
Gemeten resultaten, nauwkeurigheidscijfers, prestatiecijfers, uitkomsten van integratietests
Een kort, eerlijk verslag van wat we hebben geleerd, wat werkte, wat ons verraste en wat dit betekent voor het volledige project
Een duidelijke aanbeveling over of we door moeten gaan, de scope moeten aanpassen of het project moeten staken
Dat laatste punt is belangrijk. Als uit de POC blijkt dat het idee niet werkt zoals je had gehoopt, laten we je dat weten. We geven je liever in week twee dat antwoord dan dat we een project opzetten op basis van een aanname die in maand zes niet meer klopt.
Waarom twee weken (en niet twee maanden)?
De meeste "verkenningsfases“ in onze sector duren veel te lang. Workshops die meerdere weken in beslag nemen. Gesprekken met belanghebbenden. Strategiedocumenten die niemand leest. Ze leveren papierwerk op in plaats van concrete resultaten, en ze kosten veel geld terwijl ze de daadwerkelijke beslissing uitstellen.
Onze POC’s werken anders. Ze zijn bewust kort, doelgericht en pragmatisch:
- Eén duidelijke vraag die beantwoord moet worden (niet vijf)
- Een of twee ontwikkelaars werken eraan (geen team)
- Eén tot twee weken van begin tot eind (niet één tot twee maanden)
- Een concreet resultaat in plaats van een presentatie
De reden waarom dit werkt, is dat de meeste softwarerisico’s zich op één of twee specifieke plaatsen bevinden, meestal bij een integratie, een algoritme of een aanname over de gegevens. Je hoeft niet het hele project te valideren. Je moet de onderdelen testen die het project zouden kunnen doen mislukken.
Een doelgerichte POC pakt die moordenaars snel op. Dat is precies waar het om draait.
Welke soorten ideeën hebben het meeste baat bij een POC?
We krijgen vragen over POC’s in verband met een breed scala aan projecten. De projecten waarbij ze zich steevast terugbetalen, zijn:
Je wilt een koppeling maken met een extern systeem dat je niet helemaal begrijpt.
Een ERP-systeem, een verouderde database, een API van een derde partij, een stuk hardware. De documentatie ziet er veelbelovend uit, maar je vermoedt dat de daadwerkelijke implementatie een rommeligere aangelegenheid zal zijn. Wij maken verbinding met het echte systeem en komen erachter hoe het zit, voordat je al de helft van een product hebt gebouwd op basis van aannames die misschien niet kloppen.
Je gokt op de nauwkeurigheid van AI.
AI maakt indruk in demo’s, maar presteert wisselend in de praktijk. Als uw project ervan afhankelijk is dat de AI met een bepaalde nauwkeurigheid taken uitvoert – zoals velden uit facturen halen, supporttickets classificeren of documenten samenvatten, dan testen wij het op uw daadwerkelijke gegevens en geven wij u gemeten nauwkeurigheidscijfers. Geen beloften van leveranciers. Echte percentages op basis van echte voorbeelden.
Je weet niet zeker of je gegevens dit idee kunnen onderbouwen.
Uw gegevens staan verspreid over verschillende systemen, zijn niet gestandaardiseerd of zijn al jaren niet meer aangeraakt. Voordat u software ontwikkelt die op die gegevens is gebaseerd, geeft een POC u inzicht in de werkelijke staat ervan en welke opschoning er in het daadwerkelijke project nodig zal zijn.
Je overweegt een ongebruikelijke architectuur.
Iets dat ‘headless’ is, in realtime werkt, multi-tenant is, op de edge wordt geïmplementeerd of op een andere manier afwijkt van het standaardpatroon. Met een POC kunnen we aantonen dat de architectuur in uw specifieke context werkt, voordat we deze definitief toepassen voor de volledige implementatie.
Je moet de interne stakeholders overtuigen.
Soms is het project technisch gezien solide, maar politiek gezien onzeker. Een werkend POC, waarmee wordt aangetoond dat het kernidee daadwerkelijk werkt, is veel overtuigender dan welke pitchdeck dan ook. We hebben gezien dat POC’s budgetten hebben vrijgemaakt die met pitches niet konden worden verkregen.
Hoe een POC bij Vulpo in de praktijk werkt
Het proces is bewust eenvoudig gehouden:
1. Een eerste gesprek.
We gaan met je om de tafel zitten, fysiek of remote, om uit te zoeken wat je idee nu precies inhoudt, waar de onzekerheden liggen en wat er moet gebeuren om het project te laten slagen. Meestal is daarvoor één vergadering voldoende. Een presentatie is niet nodig.
2. We schrijven de vraag op.
Samen spreken we af welke één of twee specifieke zaken de POC moet bewijzen of weerleggen. Concreet en toetsbaar. "Kunnen we deze vijf velden uit dit type document halen met een nauwkeurigheid van ten minste 90%?", niet "de mogelijkheden van AI verkennen."
3. Wij bieden u een vaste prijs en een vast tijdschema.
Een POC van twee weken heeft een duidelijke omvang, een duidelijk eindresultaat en duidelijke kosten. Geen facturering op uurbasis zonder vaste looptijd. Je weet precies waar je aan begint voordat we van start gaan.
4. Wij bouwen het.
Snelle keuze van de stack, geen gedoe met de infrastructuur, geen gepolijste gebruikersinterface. Werkende code die de vraag beantwoordt. We werken in het openbaar; je kunt gedurende deze twee weken op elk moment meekijken.
5. Je krijgt een duidelijk antwoord.
Uiteindelijk krijg je een werkende demo, de meetresultaten, een eerlijk verslag en een aanbeveling. Jij beslist wat er daarna gebeurt: de volledige ontwikkeling laten uitvoeren, de omvang aanpassen of afzien van het project. Alle drie zijn legitieme uitkomsten.
Als je besluit om het volledige project uit te voeren, komt de kennis die je tijdens de POC hebt opgedaan direct van pas bij de uitvoering: betere architectuurkeuzes, nauwkeurigere ramingen en minder verrassingen.
De kostenkwestie, eerlijk beantwoord
Een POC van twee weken kost een paar duizend euro. Het volledige project kan je tienduizenden euro’s of meer besparen.
Als uit de POC blijkt dat je idee deugdelijk is, heb je een klein bedrag uitgegeven om het volledige project met vertrouwen en concrete kennis van start te laten gaan. Dat is het zeker waard.
Als uit de POC blijkt dat de aanpak een fatale tekortkoming vertoont, heb je een klein bedrag uitgegeven om te voorkomen dat je veel meer zou moeten uitgeven aan een project dat toch niet zou hebben gewerkt. Dat maakt het des te meer de moeite waard.
Er is vrijwel geen enkel scenario waarin het POC het duurste onderdeel van het geheel is. Het is juist de goedkope verzekering tegen de dure scenario’s.
Wanneer je waarschijnlijk geen POC nodig hebt
Eerlijk gezegd is een POC niet voor elk project nodig. We laten je meteen weten als een POC geen meerwaarde oplevert. Meestal kun je het overslaan wanneer:
Het project maakt gebruik van goed begrepen technologie in een standaardconfiguratie
De integraties en gegevensbronnen zijn goed gedocumenteerd en voorspelbaar
Je hebt eerder iets soortgelijks gebouwd en weet hoe de onderdelen in elkaar passen
Het totale budget is klein genoeg om fouten goedkoop te maken
In die gevallen gaan we meteen aan de slag. POC’s bewijzen hun nut wanneer er sprake is van echte onzekerheid, niet wanneer de weg al duidelijk is.
Klaar om je idee te testen?
Als je al een tijdje met een software-idee rondloopt maar niet zeker weet of het ook echt zou werken, of als je een hoog projectbudget aangeboden hebt gekregen en de meest risicovolle aannames wilt toetsen voordat je je vastlegt, dan is een POC vrijwel zeker de juiste volgende stap.
Vertel ons over je idee. Meestal kunnen we tijdens één gesprek vaststellen of een POC zinvol is, wat ermee bewezen moet worden en wat de kosten zouden zijn. Geen druk om je vast te leggen, geen presentatie nodig.
Vraag je POC aan
