Zo bouw ik een werkende app in drie weken: week voor week

Week 1: eerst het fundament, dan de rest

De duurste fout bij het bouwen van een app wordt gemaakt voordat er één regel code is geschreven: beginnen bij het scherm. In week één bepaal ik wat de app wel doet, voor wie hij precies werkt en welke route die ene gebruiker afloopt. Ontwerp en code komen daarna, en alleen voor dat stuk.

**Scope bepalen.** Ik schrijf op één A4 wat het probleem is, wie de kerngebruiker is en welke ene flow als eerste echt moet werken. Al het andere gaat naar een lijst met de titel later, niet naar de prullenbak. Die ene flow is de ruggengraat: staat die overeind, dan is de rest uitbreiding. Staat die niet, dan maakt het aantal schermen niets meer uit.

**Kerngebruiker en belangrijkste flow.** In het eerste gesprek lopen er vaak drie doelgroepen door elkaar en vijf wensen die allemaal even belangrijk lijken. Ik kies de gebruiker met het grootste probleem en de handeling die het vaakst terugkomt. Dat voelt als schrappen, maar het is de enige manier om in twee tot drie weken iets werkends op te leveren in plaats van drie halve schermen.

**Technische uitgangspunten.** Ik kies bewezen bouwstenen en maatwerk alleen waar het echt moet: inloggen, een database en hooguit één externe dienst. Wat je nu niet aansluit, houd je later makkelijker open dan dat je het moet afbreken. De app hoeft niet indrukwekkend te zijn, hij moet het doen.

**Eerste werkende basis.** Aan het eind van week één is er iets dat je kunt openen en doorlopen. Geen polish, geen fraaie lege staten, wel de kernhandeling van begin tot eind met data die ergens aankomt. Dat is precies wat ik bij een platform als Bijeen.app als eerste oplever: één flow die loopt, en van daaruit verder bouwen. Fouten zijn op dat moment nog goedkoop.

Zo ziet de basis van de Rapid Solution Studio eruit: een werkende eerste versie van een app, platform of proces in twee tot drie weken, tegen een vaste prijs. Week twee en drie staan in de volgende delen. Twijfel je of jouw idee in dat venster past? Plan dan een gratis gesprek van 30 minuten, of leg je vraag eerst voor aan Iris, de AI-assistent op WeAreImpact.nl. Ik neem maximaal drie lopende opdrachten aan.

Week 2: de kern werkend maken en de rest bewust laten liggen

De grootste fout in week twee is dat ineens alles af moet. De vraag is niet wat er nog bij kan, maar welke ene handeling de app echt nuttig maakt voor de mensen die hem gaan gebruiken.

In week twee bouw ik de belangrijkste functionaliteit van begin tot eind werkend: echte invoer, echte verwerking, echt resultaat. Geen scherm dat mooi staat te wezen, maar een route die iemand van de eerste klik naar de uitkomst brengt. Wat daar niet voor nodig is, gaat naar een lijst en blijft daar staan tot na de eerste test. Ik bouw liever een lelijke route die werkt dan een strak scherm dat niets doet.

Die eerste test houd ik bewust klein en vroeg. Ik zet de werkende versie neer bij een paar mensen die het probleem echt hebben en kijk waar ze vastlopen. Niet vragen wat ze ervan vinden, maar meekijken wat ze doen. De feedback die dan komt is zelden wat ik had verwacht, en dat is precies het punt. Ik noteer alles, maar bouw niet alles. Ik kies de twee of drie punten die het verschil maken tussen wel of niet bruikbaar, en de rest gaat terug de lijst in.

Scope bewaken is in deze week een dagelijkse bezigheid, geen eenmalig gesprek. Elke keer dat ik denk "dit is ook handig", is dat een keuze en geen vanzelfsprekendheid. Ik toets hem aan één vraag: maakt dit de kernhandeling beter of alleen maar voller? Bij twijfel wacht hij. Aan het eind van week twee staat er iets dat iemand anders zelf kan openen en gebruiken, zonder dat ik erbij zit om het uit te leggen. Dat is de lat. De mooiste oplossing is de oplossing die werkt, en de rest mag later.

Week 3: afronden en opleveren

Na twee weken bouwen is de verleiding groot om er nog van alles bij te maken. Dat is precies waar projecten uitlopen. De laatste week gaat niet over meer functionaliteit, maar over kiezen wat echt telt en dat afmaken. Een werkende eerste versie is een app waarin de hoofdtaak van de gebruiker foutloos lukt, niet een app waarin alle bedachte ideeën een plek hebben gekregen.

Ik begin week 3 met schrappen. Wat is de ene handeling waar de gebruiker voor komt? Alles wat daar niet aan bijdraagt gaat naar een lijst voor later. Die lijst bespreek ik met de opdrachtgever, zodat vooraf vastligt wat er bewust niet in zit. Dat voorkomt teleurstelling bij de oplevering en discussie over wat er nog bij had gemoeten.

Daarna test ik de app zoals een gebruiker hem gebruikt, met echte gegevens in plaats van een ingestudeerd voorbeeld. Ik nodig ook iemand uit die niet bij het bouwen betrokken is en laat die zonder uitleg een taak uitvoeren. Binnen een paar minuten zie je waar het misgaat: een knop die niet reageert, een leeg scherm zonder uitleg, een formulier dat niets terugzegt na opslaan. Dat repareer ik eerst, want kwaliteit zit in die kleine momenten en niet in het aantal schermen.

Dan maak ik de app overdraagbaar. Accounts en omgevingen komen op naam van de klant, er is korte documentatie over hoe het in elkaar zit en iemand uit het team loopt mee. Als ik morgen wegval, moet het door kunnen zonder mij. Dat is geen formaliteit, dat is onderdeel van de oplevering.

Ik sluit af met een demonstratie op echte data, niet met een verhaal over wat er allemaal nog kan. We leggen vast wat er staat, wat de eerstvolgende stap is en wie die oppakt. De gebruiker en de opdrachtgever houden de eindcontrole; ik lever het gereedschap, zij bepalen of het klopt.

Wil je zelf zo'n drieweekse oplevering? De eerstvolgende stap is een gratis gesprek van dertig minuten via weareimpact.nl.