Wat een prototype-first aanpak er in de praktijk uitziet

Er is een standaard manier waarop digitale projecten beginnen bij de meeste bureaus: intake, discovery, analyse, presentatie, akkoord, daarna bouwen. Ergens in die reeks verdwijnen weken, soms maanden, aan papier dat nog niets laat zien.

Bij Livewall doen we dat anders. We beginnen met bouwen. Niet als symbool van voortvarendheid, maar omdat we hebben geleerd dat een werkend prototype meer duidelijkheid geeft dan welk document ook. Het maakt abstracte ideeën concreet, dwingt echte beslissingen af en laat de opdrachtgever in week een al iets vasthouden.

Dat klinkt eenvoudig. De praktische implicaties zijn dat niet. Een prototype-first aanpak verandert hoe je een project opstart, hoe je een team samenstelt, hoe je een opdrachtgever betrekt en hoe je met onzekerheid omgaat. Dit is hoe het er bij ons concreet uitziet.

Week een: geen specificaties, wel een prototype

Het eerste wat we doen na een intake is niet een document schrijven. We stellen twee of drie kernvragen: wat is de primaire actie die een gebruiker moet kunnen uitvoeren, welk gevoel moet dat geven en wat is het riskantste onderdeel van het concept?

Dan bouwen we. Niet de volledige applicatie, maar het meest onzekere stuk. Dat prototype is rauw. Het heeft geen afgewerkte UI, geen foutafhandeling, soms niet eens echte data. Maar het werkt, en je kunt het aanwijzen.

In die eerste week zit al een patroon dat de rest van het project bepaalt: beslissingen worden genomen op basis van wat je ziet, niet op basis van wat je je voorstelt. Dat is geen kleine verschuiving. Voor opdrachtgevers die gewend zijn aan watervalprocessen is dit soms even wennen. Maar vrijwel zonder uitzondering zeggen ze achteraf: dit had ik niet verwacht, maar het werkt veel beter.

Klein team, week-doelen, geen tussenlagen

Een prototype-first aanpak werkt alleen als het team klein genoeg is om snel te handelen. Bij ons werken maximaal drie mensen op een project in de beginfase. Geen uitgebreide projectmanagementlagen, geen wekelijkse statusupdates aan een stuurgroep.

Elke week heeft een doel dat concreet en toetsbaar is. Niet 'discovery afronden' of 'designs reviewen', maar 'de flow van aanmelden tot eerste gebruik werkt en is getest met twee echte gebruikers'. Als dat doel niet haalbaar blijkt, is dat ook informatie: het vertelt ons dat de scope te groot was of dat er iets fundamenteels onduidelijk was. Dat lossen we dan op, niet over twee sprints.

Dit veronderstelt vertrouwen van de opdrachtgever in het team. Dat vertrouwen bouwen we op door transparantie: elke week is er iets te zien. Geen slides over voortgang, maar echte voortgang.

Hoe beslissingen anders werken

In een traditioneel traject worden grote beslissingen genomen op basis van specificaties en mockups. Die documenten zien er overtuigend uit, maar ze zijn statisch. Ze simuleren een ervaring die nog niet bestaat. Het gevolg: pas als het gebouwd is, ontdek je wat er niet klopte in de aannames.

Bij een prototype-first benadering komen die ontdekkingen vroeg. Soms al in week twee. We bouwen het riskantste stuk eerst, zodat we zo snel mogelijk weten of het concept klopt. Als het niet klopt, passen we aan. Dat is geen falen, dat is het systeem dat werkt zoals het bedoeld is.

Een concreet voorbeeld: bij de ontwikkeling van Sportvisunie was de grote vraag of sportvissers daadwerkelijk een digitaal community-platform zouden gebruiken. In plaats van maanden onderzoek deden we een werkende versie live met een kleine groep. Binnen twee weken wisten we wat werkte, wat niet en wat anders moest. Dat stuurde de rest van het project.

Datzelfde principe zagen we bij Lefboom: een duurzaamheidsbeloningsplatform waarbij we vroeg testten of de beloningsmechanic aansloeg. Door dat eerste prototype snel in handen te geven van echte gebruikers, kon het product al vroeg in de juiste richting worden bijgestuurd.

Wat de opdrachtgever in week een ziet

Dit is misschien wel het meest zichtbare verschil met een conventioneel bureau. In week een tonen we geen presentatie met een projectplan en een tijdlijn. We tonen iets dat werkt.

Dat kan een klikbaar prototype zijn in een browser. Het kan de eerste echte functionaliteit zijn van het systeem dat gebouwd wordt. Het kan een technische 'spike' zijn die laat zien dat een integratie haalbaar is. Wat het ook is, het is geen slide.

Die eerste concrete output zorgt voor twee dingen. Ten eerste: de opdrachtgever krijgt een reeel beeld van wat er gebouwd wordt, veel eerder dan in een traditioneel proces. Ten tweede: feedback wordt concreet. Mensen kunnen niet abstract reageren op iets wat ze voor zich zien. Ze zeggen 'dit knopje zit verkeerd' of 'deze flow klopt niet', niet 'ik vraag me af of gebruikers dit intuïtief vinden'. Dat soort feedback kun je gebruiken. Abstracte twijfels kun je niet bouwen.

De rol van AI in onze prototype-first aanpak

AI heeft onze manier van werken de afgelopen tijd concreet versneld. Niet als hype, maar als gereedschap in de handen van mensen die weten wat ze bouwen. We gebruiken AI in de vroege prototypefase om sneller een werkend skelet te genereren, standaardstructuren te bouwen en iteraties te versnellen.

Dat betekent dat de tijd tussen 'idee' en 'werkend prototype' korter is geworden. Soms gaat dat nu in dagen in plaats van weken. Dat maakt het economisch haalbaar om meer varianten te testen, meer risico's vroeg te ontdekken en met meer zekerheid te beginnen aan de bouwfase.

Onze zusterorganisatie Mach8 focust specifiek op AI-automatisering in werkprocessen. Waar we bij Livewall AI inzetten in het bouwen van digitale producten, helpt Mach8 organisaties om AI structureel in hun eigen processen te verweven. Bij projecten waar beide disciplines overlappen, werken we samen.

Voor KLM ontwikkelden we via een AI-gedreven workflow een systeem voor schaalbare campagneproductie. Dat project begon ook klein: eerst begrijpen of het concept werkte, dan pas opschalen. Prototype-first, ook als het gaat om AI-tooling.

Begin klein, groei groot

De meeste van onze grootste projecten zijn begonnen als kleine prototypes. Dat is geen toeval, het is strategie.

Een MVP is geen afgeslankte versie van een groter product. Het is de scherpste versie van het meest centrale idee. Als dat idee werkt, groeit het. Als het niet werkt, heb je niet een jaar verspild aan iets wat nooit had moeten bestaan.

Bij Zorg van de Zaak begonnen we met een kern die de primaire gebruikersbehoefte beantwoordde. Gaandeweg werd het een volwaardig B2B-platform. Bij Dumpert bouwden we de videostreaming-app van de grond af opnieuw op, maar de eerste stap was begrijpen welk deel van de bestaande app mensen echt waardeerden. Daarna pas bouwen.

Die aanpak vereist bereidheid om te beginnen voordat alles bekend is. Dat is oncomfortabel voor organisaties die gewend zijn aan volledige specificaties voor ze akkoord gaan. Maar het is eerlijker: het echte risico zit niet in beginnen zonder volledig plan, het zit in maanden plannen zonder ooit te testen of het plan klopt.