Van idee naar prototype in twee weken: hoe ziet dat traject er in de praktijk uit?

Ik analyseer het artikel en de beschikbare URLs om maximaal 3 logische interne links toe te voegen. Geschikte plaatsen: 1. "Een MVP (Minimum Viable Product) is een stap verder" → link naar MVP-pagina 2. "werkend prototype" in de conclusie/praktijksectie → link naar prototype-ontwikkeling dienst 3. "Proof of Value-trajecten" in de FAQ → link naar Proof of Value pagina ---

Je hebt een concreet idee voor een digitaal product, een geautomatiseerd proces of een slimme AI-toepassing. De gedachte is helder, het probleem is reëel — maar of het technisch haalbaar is, of gebruikers er daadwerkelijk wat aan hebben, dat weet je nog niet. En eerlijk gezegd wil je daar geen zes maanden en een fors budget voor uittrekken voordat je het weet.

Dit is een situatie die veel ondernemers, productmanagers en innovatieteams herkennen. De vraag is dan: hoe valideer je een idee snel genoeg om een onderbouwde beslissing te kunnen nemen, zonder dat je direct vastlegt voor een langdurig en kostbaar traject?

Een prototype in twee weken bouwen is één van de meest directe antwoorden op die vraag. Niet als shortcut naar een kant-en-klaar product, maar als gerichte methode om de belangrijkste aannames achter je idee zo snel mogelijk in de praktijk te testen. In dit artikel leggen we stap voor stap uit hoe zo'n traject er in de praktijk uitziet, wat jij als opdrachtgever aanlevert, wat je kunt verwachten en — net zo belangrijk — wanneer deze aanpak wél of niet de juiste keuze is voor jouw situatie.

Wat bedoelen we eigenlijk met een 'prototype'?

Prototype, MVP of definitief product: wat is het verschil?

Voordat we het over het traject hebben, is het belangrijk om begripsverwarring te voorkomen. Een prototype is niet hetzelfde als een MVP, en een MVP is niet hetzelfde als een productie-ready systeem. De termen worden in de praktijk regelmatig door elkaar gebruikt, maar ze hebben elk een eigen doel.

Een klikbaar prototype — ook wel een interactief mockup of wireframe — is een visuele weergave van een product. Er zit geen functionele technologie achter; het is bedoeld om een idee te communiceren en te toetsen op gebruikerservaring en interface-logica.

Een werkend prototype gaat een stap verder: hier zit wel degelijk functionele technologie achter, maar de scope is bewust beperkt. Het doel is niet om alles te bouwen, maar om precies genoeg te bouwen om de centrale aanname te testen. Denk aan een AI-tool die één type klantvraag verwerkt en daarmee aantoont dat de technische aanpak werkt — niet een systeem dat meteen alle twintig varianten aankan.

Een MVP (Minimum Viable Product) is een stap verder: een eerste versie van een product met voldoende functionaliteit om bij een echte gebruikersgroep te worden ingezet en te leren van hun gedrag. Dat is een ander type traject, met meer scope en een langere doorlooptijd.

Wanneer we het bij BrendR hebben over een prototype in twee weken, bedoelen we een werkend prototype: functionele technologie, beperkte scope, gericht op het testen van één of enkele kritische aannames.

Wat een prototype wél en niet doet

Een prototype maakt aannames zichtbaar. Het geeft stakeholders iets om te ervaren in plaats van iets om over te praten. En het levert concrete informatie op waarmee een go/no-go beslissing onderbouwd kan worden.

Wat een prototype niet doet: het vervangt geen doordachte productontwikkeling, heeft geen schaalbare architectuur en is niet bedoeld voor gebruik door grote aantallen eindgebruikers. Een korte, eerlijke kanttekening is hier op zijn plaats: een prototype levert bewijs, geen garanties. Niet elk idee is na twee weken klaar voor een volgende investering. Soms bewijst het prototype juist dat het idee anders moet of helemaal niet werkt. Ook dat is waardevolle — en soms dure fouten besparende — informatie.

Wanneer is een prototype in twee weken de juiste keuze?

Signalen dat je er klaar voor bent

Er zijn situaties waarin een prototype bouwen in twee weken precies de juiste stap is. Je herkent ze aan de volgende kenmerken:

• Er is een concreet idee, maar de technische haalbaarheid is onzeker.
• Stakeholders of investeerders moeten iets kunnen zien of ervaren voordat zij budget vrijmaken.
• Er is een specifieke aanname die gevalideerd moet worden — bijvoorbeeld: "gebruikers begrijpen dit proces intuïtief" of "dit type data is voldoende om de automatisering te laten werken".
• De organisatie wil voorkomen dat zij maanden bouwen aan iets waarvan de kernhypothese nog niet is getoetst.

Wanneer het nog niet de juiste stap is

Een prototype in twee weken werkt het best als er al een helder idee en een concreet probleem op tafel liggen. Is het idee nog te vaag, is de doelgroep nog niet gedefinieerd of ontbreekt er een centrale aanname om te testen, dan is prototypen te vroeg. Je bouwt dan iets zonder te weten wat je wilt bewijzen.

Ook als de verwachting is dat er na twee weken een volledig afgewerkt product ligt, of als er na oplevering geen capaciteit of bereidheid is om iets met de uitkomsten te doen, is dit niet de juiste stap. In dat geval biedt een conceptvalidatietraject een betere basis: eerst scherp krijgen wat het idee precies is en welke aannames echt kritisch zijn, voordat er gebouwd wordt.

Hoe ziet het traject van twee weken er in de praktijk uit?

Vóór de start: intake en scopebepaling

Het succes van een prototype in twee weken staat of valt bij wat er vóór dag één wordt vastgelegd. In de intake worden de volgende vragen concreet beantwoord:

• Wat is het idee en wat is het onderliggende businessprobleem?
• Welke aanname(s) moeten na twee weken gevalideerd zijn?
• Wie is de gebruiker of stakeholder die het prototype test?
• Wat is het gewenste bewijs — wat moet je ná twee weken weten om een beslissing te kunnen nemen?

Dit is geen vrijblijvend kennismakingsgesprek. De uitkomst van de intake bepaalt direct wat er gebouwd wordt en — minstens zo belangrijk — wat er bewust buiten scope blijft. Die keuze maken is essentieel: zonder heldere afbakening verwatert de focus en wordt twee weken al snel te weinig tijd.

Week 1: van aanname naar werkende basis

Dag 1 en 2 — Vertaling naar bouwblokken: De businessvraag wordt vertaald naar concrete technische en functionele keuzes. Welke technologie past bij het doel, zonder overkill? Wat valt expliciet buiten scope en waarom is dat een bewuste keuze? Dit is het moment waarop de brug wordt geslagen tussen het idee en de uitvoering.

Dag 3 tot en met 5 — Bouwen van de kernfunctionaliteit: De focus ligt uitsluitend op de functionaliteit die de centrale aanname raakt. Er wordt iteratief gebouwd: korte feedbackcycli, geen watervalontwikkeling. Het gaat er niet om zoveel mogelijk te bouwen, maar om het juiste te bouwen. Een AI-prototype dat één type klantvraag verwerkt, niet een systeem dat meteen voor alle twintig varianten klaar is.

Week 2: testen, verfijnen en conclusies trekken

Dag 6 tot en met 8 — Eerste tests en feedback: Het prototype wordt intern getest of voor de eerste keer aan potentiële gebruikers of stakeholders getoond. Wat werkt? Wat verwarrt? Wat ontbreekt? Op basis van directe observaties worden kleine aanpassingen doorgevoerd. Grote herzieningen passen niet in dit stadium — en als die nodig blijken, is dat zelf al een waardevolle conclusie.

Dag 9 en 10 — Verfijning en oplevering: Het prototype wordt presenteerbaar gemaakt voor de relevante beslissers. Tegelijk wordt gedocumenteerd wat er geleerd is: welke aannames zijn bevestigd, welke zijn weerlegd, wat is er onverwacht naar voren gekomen? Op dag tien wordt het werkende prototype gepresenteerd samen met onderbouwde conclusies. De organisatie beschikt nu over een concrete basis voor een go/no-go beslissing over de volgende stap.

Wat lever jij aan als opdrachtgever?

De input die het verschil maakt

Een prototype in twee weken vraagt ook iets van de opdrachtgever. Niet in de vorm van technische documentatie of uitgewerkte designs — maar in de vorm van beschikbaarheid en helderheid. Concreet gaat het om:

• Een helder geformuleerd idee en het onderliggende businessprobleem.
• Inzicht in de gebruiker of doelgroep: wie test het prototype en waarom?
• Beschikbaarheid voor korte afstemming en snelle feedback gedurende het traject.
• De bereidheid om keuzes te maken over wat buiten scope valt.

Wat je niet hoeft aan te leveren

Je hoeft geen volledig uitgewerkt programma van eisen aan te leveren. Geen kant-en-klare wireframes of designs. En ook geen technische kennis van de technologie die gebruikt gaat worden. BrendR neemt dat deel uit handen: van de vertaling van de businessvraag naar een werkende technische oplossing.

Wat levert twee weken bouwen op — en wat niet?

Concrete opbrengsten na twee weken

• Een werkend prototype dat de centrale aanname test.
• Eerste gebruikersfeedback of stakeholder-reacties op de werkende oplossing.
• Onderbouwde aanbevelingen voor de volgende stap: doorbouwen, bijsturen of stoppen.
• Tijdwinst en kostenbesparing ten opzichte van direct doorontwikkelen zonder validatie.

Wat twee weken niet oplevert

Een schaalbaar, productie-ready systeem. Volledige marktvalidatie bij grote gebruikersgroepen. En ook geen zekerheid — wél een stuk minder onzekerheid dan je had. Eerlijk gezegd levert het soms ook het bewijs op dat een idee fundamenteel anders moet of in de huidige vorm niet werkt. Dat voelt ongemakkelijk, maar het is precies waarvoor dit soort trajecten bedoeld zijn: zo vroeg en goedkoop mogelijk ontdekken wat werkt en wat niet.

Een voorbeeld uit de praktijk

Een middelgroot logistiek bedrijf had het idee om een deel van hun klantenservice te automatiseren met behulp van AI. Medewerkers besteedden dagelijks uren aan het beantwoorden van repetitieve vragen over zendingstijden, statussen en retourmogelijkheden. De vraag was: is het technisch haalbaar om dit te automatiseren met de gegevens die we al hebben, en willen klanten überhaupt met een geautomatiseerd systeem communiceren?

In de intake werd de centrale aanname scherp gesteld: "Een AI-assistent kan op basis van onze bestaande orderdata 70% van de meest gestelde klantvragen correct en begrijpelijk beantwoorden." Dat werd het enige dat in twee weken getest moest worden — niet een volledig geïntegreerd systeem, maar een werkende kern die deze ene aanname kon bewijzen of weerleggen.

Na twee weken lag er een werkend prototype dat werd getoond aan een kleine groep medewerkers en testte met geanonimiseerde historische klantvragen. De uitkomst: de technische aanname klopte, maar de toon van de gegenereerde antwoorden sloot niet aan op de verwachting van klanten. Een bijsturing in de aanpak, niet een fundamentele herziening.

Op basis van die inzichten besloot de organisatie door te investeren in een volgende iteratie — met een concrete aanpassing in de aanpak en een veel helderdere scope dan aan het begin van het traject.

Veelgestelde vragen over prototypen in twee weken

Wat kost een prototype laten bouwen?

De kosten van een prototype zijn afhankelijk van meerdere factoren: de complexiteit van de aanname die getest moet worden, de technologie die daarvoor nodig is en de scherpte van de scope. Een prototype dat draait op bestaande data en een bekende technologie is anders geprijsd dan een prototype waarbij eerst datastructuren in kaart gebracht moeten worden. Voor een concrete inschatting is een gesprek de meest eerlijke eerste stap.

Kan elk idee in twee weken geprototyped worden?

Nee, niet elk idee leent zich voor een prototype in twee weken. De belangrijkste randvoorwaarden zijn: een heldere aanname om te testen, een afgebakende scope en voldoende beschikbare input (zoals data of toegang tot relevante gebruikers). Is de aanname nog te breed of het idee nog te vaag, dan is twee weken niet genoeg — of bouwen we iets zonder te weten wat we willen bewijzen. In dat geval is een conceptvalidatietraject een betere eerste stap.

Wat gebeurt er ná het prototype?

De uitkomst van een prototype bepaalt de volgende stap. Mogelijke richtingen zijn: doorontwikkeling naar een volwaardig product of MVP, aanpassing van het concept op basis van de bevindingen, of de beslissing om niet verder te investeren in deze richting. Voor organisaties die willen doorontwikkelen biedt BrendR ook Proof of Value-trajecten aan, waarbij de validatie verder verdiept wordt voordat de volledige productie-investering wordt gedaan.

Hoe verschilt dit van wat een traditioneel softwarebureau doet?

Het fundamentele verschil zit in het doel. Een traditioneel softwaretraject begint doorgaans bij een uitgewerkte set van specificaties en eindigt bij een opgeleverd product. Het primaire doel is bouwen en opleveren. Bij een prototype-aanpak is het primaire doel leren: zo snel en zo goedkoop mogelijk bewijs verzamelen over een specifieke aanname, zodat een organisatie een onderbouwde beslissing kan nemen over verdere investering. Bouwen is het middel, niet het doel.

Conclusie: eerst leren, dan investeren

Een prototype in twee weken is geen manier om snel een af product op tafel te leggen. Het is een bewuste methodiek om snel te ontdekken of een idee de moeite waard is om verder in te investeren — en zo ja, in welke richting. Je reduceert onzekerheid, je geeft stakeholders iets concreets om op te reageren en je voorkomt dat maanden werk en een fors budget worden gestoken in aannames die nooit zijn getoetst.

De waarde zit niet alleen in wat het prototype bewijst. De waarde zit ook in wat het weerlegt, bijstelt of nuanceert. Een idee dat na twee weken anders blijkt te werken dan verwacht, is geen mislukt project — het is een traject dat je heeft behoed voor een veel grotere vergissing.

Staat er een idee op de plank waarvan je wilt weten of het technisch haalbaar is, of het daadwerkelijk waarde oplevert? Neem contact op voor een vrijblijvend gesprek. Of bekijk hoe BrendR vergelijkbare organisaties begeleidt via onze trajecten voor conceptvalidatie, prototype-ontwikkeling en MVP-ontwikkeling.