Hoe kom je van idee naar een eerste versie?

Het is verleidelijk om direct te gaan bouwen. Toch scheelt een half uur nadenken je dagen werk. Schrijf op één A4 op:

• Voor wie is het? Niet "iedereen", maar bijvoorbeeld "zzp-fysiotherapeuten met een eigen praktijk".
• Welk probleem los je op? "Ze plannen afspraken nu via WhatsApp en raken het overzicht kwijt."
• Wat is de ene handeling die het probleem oplost? "Een patiënt kiest zelf een tijdslot en de therapeut ziet het in een overzicht."
• Hoe weet je of het werkt? "Drie therapeuten gebruiken het een week en willen ermee doorgaan."

Dat is denkwerk dat alleen jij kunt doen. Het is meteen de basis van een goede opdracht aan je AI, en van elk gesprek met iemand die je helpt bouwen. Wat een goede opdracht is, lees je in Goed vragen aan je AI.

Een MVP (minimum viable product) is de kleinste versie van je idee waarmee je kunt testen of mensen het willen gebruiken. Het woord "kleinste" is daarbij het belangrijkst.

In een eerste versie hoort:

• de ene kernhandeling, van begin tot eind;
• net genoeg opmaak om het te snappen;
• een manier om te zien of mensen het gebruiken.

Niet in een eerste versie hoort:

• een beheeromgeving met tien instellingen;
• vijf manieren om in te loggen;
• betalingen, als je nog niet weet of mensen het willen;
• een app voor de App Store, als een webapp ook kan.

Alles wat je weglaat, hoef je ook niet te beveiligen, te testen en te onderhouden.

Welke tool past, hangt af van je idee en van hoeveel je zelf wilt doen. Zie Welke tool past bij jou?

Een eerste versie groeit het best in deze volgorde:

1. De schermen, met nepgegevens. Zo zie je of de flow klopt voordat er een database aan hangt.
2. De opslag, in een database: de plek waar je app gegevens bewaart.
3. Inloggen, als het nodig is. Dat hoort via een bestaande dienst te gaan, niet via iets zelfgebouwds. Zie Inloggen en gebruikers.
4. Controles op invoer. Wat gebeurt er als iemand een veld leeg laat of onzin invult?

Na elke stap hoort een test en een bewaarde werkende versie (opent in een nieuw tabblad)¹. Hoe eerder de code in GitHub staat, hoe eerder er een kopie buiten je tool (opent in een nieuw tabblad)² is. GitHub is een dienst waar code met de hele geschiedenis van alle wijzigingen bewaard wordt.

Eerder dan je denkt. Zodra de kernhandeling werkt, laat je het aan drie tot vijf mensen uit je doelgroep zien. Kijk mee terwijl ze het gebruiken en leg niets uit. Waar ze vastlopen, zit je volgende verbetering.

Let op: zolang je project nog een prototype is, horen er geen echte gevoelige gegevens in. Werk met nepnamen en testadressen, of laat het zien op je eigen scherm. Een prototype is zelden goed beveiligd, en voor echte persoonsgegevens gelden de regels van de AVG (opent in een nieuw tabblad)³. Zie Privacy en de AVG.

Een paar valkuilen die veel voorkomen:

• Te veel tegelijk willen. Na een week zijn er twintig half werkende functies en geen enkele die af is. Eén ding afmaken werkt beter.
• Alleen op je eigen laptop testen. De meeste mensen openen een link op hun telefoon.
• Geen versies bewaren. Eén verkeerde prompt kan veel stuk maken. Met een bewaarde versie ben je in een minuut terug.
• Echte gegevens gebruiken om te testen. Je eigen klantenlijst in een prototype zetten voelt handig, maar is een risico.
• Alles aan de AI overlaten. Je hoeft niet te leren programmeren, wel je eigen project te kennen: wat het doet, welke gegevens erin staan en waar.

Als mensen je eerste versie willen gebruiken, verandert de vraag. Het gaat dan niet meer om "werkt het?", maar om "kan ik dit veilig aan echte gebruikers geven?". Dat is een andere klus, met beveiliging, back-ups, een eigen domein en vaak betalingen.

Waar vibecoden ophoudt, lees je in Wat kan vibecoden niet? Wat er voor een product nodig is, staat in Van prototype naar product. Dat werk hoef je niet zelf te doen: we zetten op een rij wat er voor jouw project nodig is en regelen het technische deel.