Razendsnel duidelijkheid over jouw idee

Je software idee snel valideren met een proof of concept

Elk software-project begint met een idee. Soms is dat idee al helder in je hoofd, soms is het nog vaag. Wat ze delen: op papier klinken ze allemaal goed. De valkuil is dat je maandenlang gaat bouwen aan iets waarvan achteraf blijkt dat de aanname niet klopte, dat gebruikers het anders willen, of dat de techniek toch niet doet wat je hoopte.

Wij bouwen proof of concepts en MVP’s die dat voorkomen. In vier tot zes weken maken we samen een werkende versie van je kernidee, klein maar echt, waarmee je binnen anderhalve maand weet of het traject waarde heeft voordat je de volledige investering doet.

Wat is een proof of concept

Een proof of concept (POC) is een compacte, werkende versie van een idee waarmee je toetst of het technisch haalbaar is en of het doet wat je verwacht. Het is geen prototype (een klikbaar model zonder werkende logica) en geen MVP (een minimaal product klaar voor de eerste betalende klanten). Een POC zit ertussen: klein genoeg om snel te bouwen, echt genoeg om de kernvraag te beantwoorden.

Kernvragen die een goed opgezette proof of concept beantwoordt:

• Is dit technisch mogelijk met de systemen en data die we hebben?
• Werkt de aanname over gebruikersgedrag die onder het idee ligt?
• Passen de gekoppelde systemen bij elkaar zoals verwacht?
• Wat zijn de risico’s die we nu nog niet zien, maar die bij grotere schaal problemen gaan geven?
• Wat kost het echt om dit vol op te bouwen, met de kennis die we uit de POC opgedaan hebben?

Een POC lost niet alle vragen op. Hij versmalt onzekerheid tot de vragen die er echt toe doen.

Verschil tussen proof of concept, prototype en MVP

Deze drie termen worden vaak door elkaar gebruikt, maar ze hebben elk een eigen doel en aanpak.

Prototype: een klikbaar model, meestal in Figma of vergelijkbaar, dat laat zien hoe iets eruit ziet. Geen werkende logica onder de motorkap. Handig voor gebruikersonderzoek en design-validatie, ongeschikt voor technische toetsing.

Proof of concept: een werkende versie met beperkte scope, gebouwd in echte techniek. Toetst haalbaarheid en aannames. Niet klaar voor productie, wel klaar om iets aan te tonen. Meestal vier tot zes weken bouwtijd.

MVP (Minimum Viable Product): de kleinst mogelijke productie-versie waarmee je echte gebruikers kunt bedienen. Alles wat niet strikt nodig is, is bewust weggelaten. Gebouwd om op te schalen naar volledige productie. Doorlooptijd meestal drie tot zes maanden.

Wij bouwen alle drie, afhankelijk van waar je nu staat. Voor puur design-validatie starten we met een prototype. Voor haalbaarheidsvragen bouwen we een POC. Voor “we willen zo snel mogelijk gebruikers” leveren we een MVP.

Wanneer een proof of concept zin heeft (en wanneer niet)

Niet elk project heeft een POC nodig. Als je precies weet wat je wilt, de techniek staat vast, en er zijn geen open vragen: begin dan gewoon met bouwen. Een POC is waardevol in situaties met echte onzekerheid.

Wel een POC:

• Je wil koppelen aan een systeem dat je nog niet eerder hebt gebruikt, en je bent niet zeker of de data die je nodig hebt beschikbaar is via de API
• Je hebt een idee voor AI-integratie, maar je weet niet of de kwaliteit van de output goed genoeg wordt op jullie eigen data
• Je overweegt een technische keuze (framework, database, cloud-platform) waar je later niet gemakkelijk vanaf komt
• Je bouwt iets waar geen precedent voor is in je organisatie, en je wil beleidsmatig zeker weten dat het werkt
• Je hebt intern draagvlak nodig om verder te investeren, en een werkende demo helpt daar meer dan een presentatie

Meestal geen POC:

• Je bouwt een variant van iets wat je (of wij) al vaker hebben gedaan (een webshop, een klantportaal, een standaard koppeling)
• Je hebt tijdsdruk waardoor de POC-fase het reguliere traject in de weg zit
• De kernvragen zijn niet technisch, maar organisatorisch of commercieel

Waar wij een proof of concept voor bouwen

Onze POC-projecten vallen bijna altijd in één van deze categorieën.

AI en machine learning
Een LLM-integratie op je eigen data, een classificatie-model op documenten of klantvragen, een aanbevelingsengine op je webshop. De vraag is meestal: werkt het goed genoeg op onze data, en is het bruikbaar in ons proces. Wij bouwen op OpenAI, Anthropic of open-source modellen, afhankelijk van wat past bij de use case.

Systemen koppelen die nog niet eerder gekoppeld zijn
Een nieuwe combinatie van bestaande software waarvan niemand met zekerheid kan zeggen dat het gaat werken. Wij bouwen een compacte werkende koppeling die de kritieke datastromen laat zien, plus een inschatting van wat er nog nodig is voor productie.

Nieuwe portalen of maatwerksoftware
Een klantportaal of stukje maatwerk waar het functionele beeld nog niet scherp is. Wij bouwen de kern-flow werkend, laten hem testen door echte gebruikers, en werken op basis daarvan een blauwdruk uit voor het volledige traject.

SaaS-ideeën en platformen
Een ondernemer of intern innovatieteam heeft een idee voor een SaaS-oplossing. Wij bouwen een compacte werkende versie waarmee je de eerste tien potentiële klanten kunt spreken, om te toetsen of de betalingsbereidheid en het probleem-oplossing-fit kloppen.

Dataverwerking en dashboards
Een idee voor een dashboard dat data uit meerdere bronnen samenbrengt. Wij bouwen een POC met echte data uit één of twee bronnen, waarin de belangrijkste KPI’s al zichtbaar zijn en de aannames over data-kwaliteit getoetst worden.

Hardware-geïntegreerde software
Een applicatie die praat met sensoren, printers, kassa-systemen of andere hardware. Wij bouwen een POC waarin de meest risicovolle koppeling écht werkt, zodat je weet of het traject überhaupt loont voordat je de volledige software laat ontwikkelen.

Onze aanpak van een proof of concept

We werken bijna alle POC’s in een vast ritme van vier tot zes weken. Kort genoeg om vaart te houden, lang genoeg om substantieel werk te leveren.

Van proof of concept naar productie

De grootste valkuil na een succesvolle POC is dat de POC-code één-op-één in productie gaat. Wij bouwen POC’s expliciet op een manier die de overstap vergemakkelijkt, maar niet iedereen doet dat. Waar we op letten voor als het traject verder gaat.

• Modulariteit: onderdelen die in productie moeten schalen, isoleren we tijdens de POC zodat we ze later goed kunnen aanpakken
• Test-dekking: kritieke logica krijgt tijdens de POC al basis-tests, zodat we niet vanaf nul beginnen bij het productie-traject
• Documentatie van beslissingen: waarom we voor techniek X kozen en niet Y wordt vastgelegd, zodat de volgende ontwikkelaar niet aan het gokken slaat
• Overdraagbaarheid: ook als je later met een ander team verder gaat, moet de POC begrijpbaar zijn. Duidelijke README, gestructureerde code, geen “quick hacks” op onlogische plekken

Voor projecten die na de POC in productie gaan, werken we typisch drie tot negen maanden verder in sprints, afhankelijk van de scope. Bekijk onze aanpak voor maatwerksoftware voor hoe die vervolgtrajecten meestal lopen.

Waar wij scherp op letten

Een POC die niet de goede vraag beantwoordt, is verspilde tijd. Dit zijn de plekken waar wij structureel bij stilstaan.

• Scope-discipline. De grootste vijand van een goede POC is scope-creep. Wij bewaken actief wat wel en niet in scope zit, en houden een parkeerlijst voor de goede ideeën die later kunnen.
• Echte data, geen mock-data. Waar mogelijk werken we in de POC met echte data uit jullie systemen. Alleen zo toets je écht of aannames kloppen.
• Echte gebruikers, geen interne stakeholders. Aan het eind van de POC willen we minimaal drie externe of eindgebruikers de software zien gebruiken. Wat zij zeggen weegt zwaarder dan wat het projectteam denkt.
• Documentatie van wat niet werkt. Een POC waarin iets niet blijkt te kunnen, is net zo waardevol als een POC waarin alles werkt. Wij leveren beide met dezelfde zorgvuldigheid op.
• Realistische inschatting van de vervolgweg. Aan het eind van elke POC leggen we vast wat er nodig is om naar productie te gaan, in tijd en complexiteit. Op basis van echte kennis, niet op basis van gevoel.
• Bewust wegwerpen mag. Soms concludeer je aan het eind van een POC dat het idee niet werkt. Dat is een succesvolle POC, niet een mislukte. Beter nu dan na een half jaar bouwen.

Bekijk voor meer context onze pagina over maatwerksoftware, over platforms op maat voor grotere schaal, of over digitale transformatie als je twijfelt of een POC de juiste eerste stap is.