De beste feature-brief die we kregen, was een prototype dat de klant zelf had gebouwd

Er is een moment in bijna elk softwareproject dat je leert herkennen. Een klant belt. Of stuurt een mail. Hij zegt dat hij iets met een dashboard wil. Dat het moet kunnen filteren. En dat het fijn zou zijn als je meteen ziet wat belangrijk is. Je luistert. Je schrijft het op. Je vertaalt het naar user stories. Daarna bouw je precies wat er gevraagd wordt.

En bij de oplevering gebeurt er iets bekends. De klant kijkt naar het scherm, aarzelt even en zegt dan:
“Ja… maar dit bedoelde ik eigenlijk niet.”

Niet omdat er slecht gebouwd is. Maar omdat er bijna altijd een gat zit tussen wat iemand zegt en wat iemand bedoelt. Dat gat heeft softwareontwikkeling jarenlang duur gemaakt. Tot voor kort.

TL;DR

De grootste kostenpost in softwareontwikkeling zit niet in het bouwen, maar in het verkeerde bouwen. Klanten kunnen hun wens vaak pas echt scherp maken zodra ze die voor zich zien. Jarenlang gebeurde dat pas ná de requirements-fase en vaak pas ná de eerste oplevering.

Nu klanten met AI-tools als Claude en ChatGPT zelf werkende prototypes maken, verschuift dat moment naar voren. Ze komen niet meer met alleen een beschrijving, maar met een klikbaar prototype. En dat prototype is vaak waardevoller dan de meest zorgvuldig geschreven user story.

Wij gebruiken zo’n prototype niet als eindproduct en ook niet als code die je één op één overneemt. We lezen het als de scherpste vorm van requirements: een tastbare vertaling van bedoeling, interactie en beleving. Precies daar begint ons werk.

Een beschrijving is altijd een interpretatie

Vraag tien mensen om een “simpele planningsmodule” te beschrijven en je krijgt tien antwoorden die op papier misschien op elkaar lijken, maar in de praktijk iets totaal anders betekenen. De een bedoelt een kalender. De ander een lijst met deadlines. Een derde bedoelt eigenlijk een capaciteitsoverzicht, maar heeft daar de woorden nog niet voor. Dat is niet omdat klanten niet weten wat ze willen. Het is omdat taal een beperkt middel is om iets interactiefs te beschrijven.

Je kunt een gevoel voor een interface moeilijk vangen in bulletpoints. Sommige dingen begrijp je pas echt wanneer je ze ziet en gebruikt. En precies daar zat jarenlang het ongemak. De klant kon pas herkennen wat hij wilde op het moment dat hij een werkend iets voor zich zag. Maar dat werkende iets kwam er pas nadat wij het gebouwd hadden, op basis van een beschrijving die per definitie nog onvolledig was.

De eerste versie van software was daardoor vaak vooral een dure manier om een gesprek te voeren. Iedereen in dit vak kent die lus. En iedereen heeft geleerd hem min of meer te accepteren. Totdat het gereedschap veranderde.

De klant komt niet meer met een verhaal, maar met een prototype

Steeds vaker ontvangen we geen document meer, maar een link. Een klant heeft in een avond met Claude of ChatGPT een werkend prototype gemaakt. Geen productiecode, natuurlijk. Technisch vaak verre van perfect. Soms een wankel bouwwerk dat vooral overtuigt zolang je niet te hard duwt. Maar dat is ook niet het punt.

Het punt is dat zo’n prototype precies laat zien wat iemand bedoelt. En dat blijkt in de praktijk veel waardevoller dan de netste user story die we ooit uit een refinement hebben gehaald. In een prototype zie je namelijk keuzes die in tekst bijna nooit goed boven tafel komen. Je ziet waar iemand een filter verwacht. Je ziet wat voor hem als overzicht voelt. Je ziet welke informatie prioriteit heeft, welke volgorde logisch aanvoelt en welke interactie vanzelfsprekend lijkt. Het prototype maakt de bedoeling tastbaar. En dat maakt het gesprek fundamenteel beter.

Want een klant kan een verkeerde beschrijving geven zonder het te weten. Een verkeerd prototype geven is veel lastiger. Hij heeft er immers zelf al mee geklikt. Hij heeft al gemerkt waar het schuurt, wat ontbreekt en wat niet logisch voelt. Het denkwerk dat vroeger pas in de eerste bouwronde gebeurde, is dan al voor een belangrijk deel gedaan. Door de enige persoon die precies weet wat hij bedoelt: de klant zelf.

Een nieuwe manier van rapid prototyping

Naast prototypes die klanten zelf bouwen, werken we inmiddels ook op een nieuwe manier samen. Meetings met klanten worden opgenomen en verwerkt binnen onze gespecialiseerde, veilige AI-omgevingen. Die data blijft volledig binnen onze eigen omgeving en wordt niet gedeeld met externe partijen zoals OpenAI of Anthropic. Op basis van die gesprekken genereren we direct een eerste werkend prototype.

Dat geeft klanten een voorsprong. Ideeën worden sneller concreet, maar vooral ook nauwkeuriger vertaald naar interactie en beleving. Voor developers betekent het dat ze niet langer werken vanuit interpretatie alleen, maar vanuit iets dat al zichtbaar, klikbaar en testbaar is. Het begrip van de klantwens wordt daardoor fundamenteel beter.

Een concreet voorbeeld: een digitale plankaart

Een van de meest inspirerende voorbeelden die we recent ontvingen, was een prototype van een digitale plankaart voor een nieuwbouwproject. De klant had met AI een interactieve kaart gebouwd waarin een compleet nieuw gebied zichtbaar werd gemaakt. Geen statische afbeelding, maar een omgeving waarin je kon navigeren. Je kon delen van het gebied highlighten, routes bekijken en schakelen tussen wandelroutes, fietsroutes en autoroutes. In één oogopslag werd duidelijk hoe alles zich tot elkaar verhield. Het was in feite een digitale maquette.

Wat dit prototype zo sterk maakte, was niet de techniek op zich, maar het gevoel dat het opriep. Je kreeg als gebruiker direct een indruk van hoe het zou zijn om daar straks te wonen. Waar je loopt. Hoe je je verplaatst. Wat dichtbij is. Wat verder weg ligt. Dat soort inzichten zijn bijna onmogelijk om goed in tekst te beschrijven. Maar in dit prototype waren ze in één keer duidelijk.

Voor ons was dit geen kant-en-klare feature, maar een extreem scherpe vraag: hoe maken we dit soort beleving schaalbaar, onderhoudbaar en bruikbaar voor meerdere projecten binnen nieuwbouwprojectwebsites? Precies daar begint het verschil tussen een slim prototype en een sterke productfeature.

Een prototype is geen product

Hier ontstaat soms verwarring. Een AI-prototype ziet er vaak overtuigend uit. Het klikt. Het reageert. Het oogt bijna af. En juist daarom is het verleidelijk om te denken dat het nog maar een kleine stap is naar een echte feature. Dat is zelden zo. Een prototype is geen product. Het is een uitstekend geformuleerde vraag.

Nieuwbouwprojectwebsites moeten veilig zijn, onderhoudbaar, schaalbaar en consistent met de rest van het platform. Niet alleen voor één klant en één project, maar voor meerdere klanten met vergelijkbare behoeften. Wat in een prototype werkt voor de duur van een gesprek, moet in een platform jarenlang overeind blijven. Daarom kopiëren we een prototype nooit letterlijk. We lezen het als specificatie.

We halen eruit wat het echt vertelt: welke interactie verwacht wordt, welke informatie prioriteit heeft, waar logica vanzelfsprekend voelt en waar frictie ontstaat. Dat vertalen we naar een feature die past binnen de architectuur van ons platform. Soms ziet het eindresultaat er anders uit dan het prototype. Dat is geen probleem. Zolang het doet wat het prototype bedoelde. Want het prototype is niet de blauwdruk. Het is de tastbare vertaling van een wens. En die wens moet uiteindelijk landen in iets dat niet alleen slim oogt, maar ook blijft staan.

De grootste winst is eigenaarschap

De zichtbare voordelen zijn duidelijk. Requirements worden scherper. Misverstanden nemen af. De doorlooptijd wordt korter. We bouwen sneller de juiste dingen. Maar de grootste winst hadden we eerlijk gezegd vooraf niet helemaal voorzien. Klanten voelen zich eigenaar van de feature. Dat klinkt misschien zacht, maar het effect is keihard. Iemand die zelf een prototype heeft gebouwd, zit anders in het gesprek. Niet als toeschouwer, maar als mede-vormgever. Hij heeft al keuzes gemaakt. Hij heeft al gezien waar iets wringt. Hij begrijpt beter waarom bepaalde keuzes lastig zijn.

Daardoor verandert de samenwerking fundamenteel. Het gesprek gaat niet meer alleen over de vraag of dit is wat hij gevraagd had. Het gaat over hoe we het samen beter kunnen maken. Dat is een ander gesprek. Eerlijker, scherper en meestal ook sneller. En die betrokkenheid blijft. Een feature die iemand mede heeft vormgegeven, wordt gebruikt. Een feature die alleen is opgeleverd, wordt hooguit geaccepteerd. Dat verschil is groter dan het lijkt. Het is het verschil tussen software die leeft en software die ergens in een menu stof staat te vangen.

Het prototype vervangt niet ons vak

Soms krijgen we de vraag of ontwikkelaars nog wel nodig zijn als klanten zelf prototypes kunnen bouwen. Het antwoord is eenvoudig: meer dan ooit, maar op de juiste plek in het proces. Een prototype maken is tegenwoordig relatief makkelijk. Een veilig, onderhoudbaar en schaalbaar platform bouwen blijft complex. AI democratiseert het begin van softwareontwikkeling, niet het einde. De drempel om een idee zichtbaar te maken is sterk verlaagd. De drempel om dat idee duurzaam te maken staat nog altijd fier overeind. En dat is precies zoals het hoort.

De klant hoeft niet langer te gokken hoe hij zijn idee moet beschrijven. Hij kan het laten zien. Klikbaar, zichtbaar en veel concreter dan ooit tevoren. Wij zorgen ervoor dat het een duurzame feature wordt die past binnen het platform, mee kan groeien en over jaren nog steeds klopt. De klant die zijn eigen feature heeft geprototypet, vraagt ons niet om minder. Hij vraagt ons om beter.

De beste feature-brief die we tegenwoordig krijgen, is daarom geen document meer.

Het is een prototype.