Het prototype versus het product: hoe je weet wanneer je met AI gebouwde app echt af is

Een paar weken geleden bouwde een oprichter die ik ken een planningsapp voor therapeuten. Het hele ding kostte haar vier dagen met een AI-appbouwer. Hij doet wat ze nodig heeft: therapeuten kunnen hun agenda zien, klanten kunnen afspraken boeken, bevestigingen gaan uit per e-mail. Het werkt.

Ze staart er nu twee weken naar en heeft hem niet gelanceerd.

Toen ik vroeg waarom, zei ze: “Het werkt, maar… het voelt niet af.”

Ik vroeg haar wat ze zou veranderen. Ze zei: “Ik weet het niet. Dat is het probleem.”

Dit is het moeilijkste moment in het bouwen met een AI-appbouwer. Het ding is functioneel, maar er is een gat tussen “functioneel” en “ik zou me prettig voelen om echte mensen te vragen dit te gebruiken”. Dat gat begrijpen — en weten aan welke kant je echt zit — is het verschil tussen lanceren en voor altijd vastzitten in de stem-in-je-hoofd-fase.

Wat “af” echt betekent

Hier is het onderscheid dat ertoe doet: een prototype is iets dat je gebruikt om een idee te testen. Een product is iets dat je gebruikt om een probleem op te lossen.

De planningsapp voor therapeuten is een prototype. Hij bewijst dat het concept werkt. Een therapeut zou hem kunnen gebruiken. Maar er zijn zeventien kleine dingen die hem ruw doen voelen:

De e-mailbevestigingen zijn kaal. Geen logo, geen aangepaste branding, generieke tekst.
Annuleringen sturen geen meldingen. Klanten komen gewoon niet opdagen.
Er is geen wachtlijst als een therapeut volgeboekt is.
De aanmeldflow verzamelt de specialismen van de therapeut niet, dus er is geen manier om op praktijktype te filteren.
Er is geen herinneringsmail die 24 uur voor de afspraak wordt gestuurd.

Geen van deze dingen breekt de app. Ze laten allemaal een echte therapeut denken: “Dit voelt als iets dat ik in een weekend in elkaar zette, niet als iets waar iemand me voor laat betalen.”

Dat gevoel is echt, en het doet ertoe. Een prototype lost het probleem in theorie op. Een product lost het in de praktijk op, voor de echte mens die het gebruikt.

Drie vragen die prototype van product scheiden

Hier is het moeilijke deel: je kunt niet alles weten dat ontbreekt. Je AI-bouwer kan het ook niet weten. Dus je hebt drie snelle vragen nodig om uit te vogelen aan welke kant van de lijn je zit.

1. Zou jij dit gebruiken om je eigen probleem op te lossen?

Deze is eerlijk, want je moet echt met je eigen product leven.

Als je de oprichter bent van die planningsapp voor therapeuten, zou je hem gebruiken om je eigen therapieafspraken te plannen? Niet “zou je kunnen” — zou je hem echt gebruiken in plaats van een e-mailketen of een gedeeld Google Doc?

Als het antwoord nee is, ben je niet klaar. Je weet precies wat er mis is — je voelt het elke keer dat je de app opent. Als het antwoord ja is, ben je dichterbij.

De oprichter die ik noemde, doorliep haar eigen therapeutaanmelding. Ze liep vast bij het formulier (het vroeg om te veel informatie voordat het haar liet boeken). Ze zag de bevestigingsmail en vond hem amateuristisch ogen. Ze begon na te denken over hoe haar therapeut de mail zou ontvangen en of die in spam zou belanden.

Ze gebruikte haar eigen product niet zoals een betalende klant zou doen. Toen ze dat deed, vond ze tien dingen om te repareren.

2. Heb je het aan drie mensen laten zien die jij niet bent?

Met potentiële gebruikers praten is moeilijker dan bouwen, en de meeste oprichters slaan het over omdat ze mensen bij de lancering willen verrassen. Dat is een fout.

Je hebt geen focusgroep nodig. Je hebt drie mensen nodig die lijken op wie jij denkt dat je klant is. Voor de therapeutenapp zijn dat drie echte therapeuten.

Hier is wat je zoekt: waar raken ze in de war? Waar aarzelen ze? Waar vragen ze naar? Niet “wat vinden ze ervan?” (mensen zijn te aardig). Vraag ze om het ding echt te doen — een afspraak boeken, een bevestigingsmail sturen, iets annuleren.

Toen de oprichter haar therapeutenapp aan drie therapeuten liet zien, vroegen er twee: “Kan ik regels instellen voor wanneer ik beschikbaar ben? Zoals, ik zie nieuwe klanten alleen op donderdag, en ik dubbelboek niet voor 14 uur.” De app had een agenda, maar geen regels. Ze had het prototype gebouwd voor hoe zij dacht dat plannen werkte, niet hoe therapeuten echt werken.

Dat is productinformatie. Dat kon je niet raden uit een specificatie.

3. Wat zou breken als je dit aan tien echte gebruikers gaf?

Dit is de moeilijkste vraag omdat hij vereist dat je echt nadenkt over je randgevallen.

Voor de therapeutenapp:

Wat gebeurt er als een klant twee afspraken op hetzelfde moment probeert te boeken? (De app checkt het niet.)
Wat gebeurt er als een therapeut een afspraak annuleert? Krijgen klanten automatisch een melding? (Nee.)
Wat als het e-mailadres van een klant verkeerd is? Is er een manier om het te repareren zonder opnieuw te beginnen? (Nee.)
Wat als een therapeut een ziektedag heeft en haar agenda een week moet sluiten? (Ze zou elke afspraak handmatig moeten verwijderen.)

Dit zijn geen bugs. De app crasht niet. Maar het zijn papiersnedes. Met tien echte gebruikers en echte randgevallen raak je ze allemaal in de eerste week.

Een product handelt de randgevallen af. Niet allemaal — sommige dingen kunnen wachten. Maar die welke in de eerste twee weken met echte gebruikers gebeuren, die moeten werken.

Hoe je beslist: de drie-lagentest

Gebruik dit om uit te vogelen waar je staat:

Laag 1: kernflow — Werkt het gelukkige pad? Kan een gebruiker het hoofdding doen waarvoor je app is ontworpen?

Voor de therapeutenplanner: ja. Iemand kan zich aanmelden, een afspraak boeken, een bevestiging krijgen. Het werkt.

Laag 2: randgevallen uit echt gebruik — Je hebt het aan drie echte gebruikers laten zien. Raakten ze iets waar je niet voor bouwde? Raakten ze ergens in de war?

Voor de therapeutenplanner: ja. De drie therapeuten wilden regelgebaseerde beschikbaarheid. Eén raakte in de war omdat de e-mailbevestiging er te generiek uitzag. Eén probeerde afspraken in bulk te verwijderen en kon dat niet.

Laag 3: afwerking en professionaliteit — Voelt het alsof je erom geeft? Of voelt het alsof je het in elkaar flanste?

Voor de therapeutenplanner: het voelt in elkaar geflanst. De e-mailbevestigingen zijn kaal. Er is geen aangepaste branding. Er is geen foutmelding als er iets misgaat, dus als er iets breekt, heeft de gebruiker geen idee wat er gebeurde.

Hier is de vuistregel:

Alle drie lagen werken? Je bent een product. Lanceer het.
Lagen 1 en 2, niet 3? Je bent voor 80% klaar. Besteed een dag aan afwerking.
Laag 1 werkt, lagen 2 en 3 niet? Je bent een prototype. Lanceer nog niet.
Laag 1 is niet stevig? Je bent niet klaar. Blijf bouwen.

De therapeutenapp zat vast op de grens tussen laag 1 en laag 2. De kernflow werkte, maar echte therapeuten vonden hem missende stukken hebben. Dus de oprichter had een keuze: nog een week met haar AI-bouwer de functies toevoegen die therapeuten echt nodig hebben, of lanceren met wat ze had en ze later toevoegen.

(Ze voegde ze toe. Het kostte drie dagen. Nu is het een product.)

Het ding dat dit moeilijk maakt

De reden dat zoveel oprichters hier vastlopen, is dat bouwen leuk is en lanceren eng.

Bouwen is een gesprek met je AI-tool. Je hebt een idee, je beschrijft het, de tool voert het uit. Er is een feedbacklus die minuten kost. Lanceren is anders. Je klikt op publiceren, en als er iets mis is, komen echte mensen erachter. Er is geen overdoen.

Dus we vinden redenen om niet te lanceren. “Het is niet gepolijst genoeg.” “Ik zou nog één functie moeten toevoegen.” “Wat als de lettertypes verkeerd zijn?” En zes weken later zit je nog steeds op iets dat werkt maar niet af voelt, en heb je jezelf ervan overtuigd dat het door de lettertypes komt.

Het zijn niet de lettertypes.

Het is meestal dat je geen tijd hebt besteed met een echte gebruiker, of dat je iets hebt gebouwd dat in je hoofd logisch was maar niet helemaal past bij hoe echte mensen werken. Dat is op te lossen. Het vereist alleen toegeven dat je niet weet wat je niet weet, en dan met iemand gaan praten die het wel weet.

De lanceergereedheidchecklist

Gebruik deze. Hij is kort en eerlijk.

Ik heb hem zelf gebruikt om de echte taak te doen, en het werkte (niet op een demo-modus-manier, maar echt).
Ik heb hem aan drie mensen laten zien die hem echt zouden gebruiken, en ik heb de dingen gerepareerd waar ze in de war over waren.
Elke fout die kan gebeuren heeft een melding die de gebruiker vertelt wat hij eraan moet doen (niet “fout”, maar echte begeleiding).
Ik zou het oké vinden als dit zes maanden de laatste versie was (betekent: hij is compleet genoeg om nuttig te zijn, zelfs als ik er nooit meer aan kom).
Ik ben enthousiaster over wat ik zal leren van echte gebruikers dan over meer functies toevoegen in een vacuüm.

Als je alle vijf vakjes kunt aanvinken, ben je klaar. Lanceer.

Als je dat niet kunt, doe het niet. Maar wees specifiek over waarom. “Het voelt niet af” is geen reden. “Echte therapeuten hebben beschikbaarheidsregels nodig en die heb ik nog niet gebouwd” is een reden. Dat is uitvoerbaar. Dat is op te lossen. Dat is het verschil tussen vastzitten en op een pad zitten.

De oprichter van de therapeutenapp lanceerde hem gisteren. Ze heeft haar eerste betalende klant. Het product is niet perfect, maar het is echt, en haar klant vertelt haar al wat ze vervolgens moet bouwen. Dat is wanneer je weet dat je klaar bent: niet wanneer de app perfect is, maar wanneer je klaar bent om te leren wat perfect echt betekent voor de mensen die hem gebruiken.