Prototypen kontra produkten: hur du vet när din AI-byggda app faktiskt är klar

För några veckor sedan byggde en grundare jag känner en bokningsapp för terapeuter. Hela grejen tog henne fyra dagar med en AI-appbyggare. Den gör vad hon behöver: terapeuter kan se sin kalender, klienter kan boka tider, bekräftelser går ut via mejl. Den fungerar.

Hon har stirrat på den i två veckor och inte lanserat.

När jag frågade varför sa hon: “Den fungerar, men… den känns inte klar.”

Jag frågade vad hon skulle ändra. Hon sa: “Jag vet inte. Det är problemet.”

Det här är det svåraste ögonblicket i att bygga med en AI-appbyggare. Grejen är funktionell, men det finns ett glapp mellan “funktionell” och “jag skulle känna mig bekväm med att be riktiga människor använda det här”. Att förstå det glappet — och att veta vilken sida av det du faktiskt är på — är skillnaden mellan att leverera och att fastna i rösten-i-ditt-huvud-fasen för evigt.

Vad “klar” faktiskt betyder

Här är distinktionen som spelar roll: en prototyp är något du använder för att testa en idé. En produkt är något du använder för att lösa ett problem.

Bokningsappen för terapeuter är en prototyp. Den bevisar att konceptet fungerar. En terapeut skulle kunna använda den. Men det finns sjutton små saker som får den att kännas oslipad:

Mejlbekräftelserna är spartanska. Ingen logotyp, ingen egen varumärkning, generisk text.
Avbokningar skickar inga notiser. Klienter dyker bara inte upp.
Det finns ingen väntelista om en terapeut är fullbokad.
Registreringsflödet samlar inte in terapeutens specialiteter, så det finns inget sätt att filtrera på praktiktyp.
Det skickas inget påminnelsemejl 24 timmar före tiden.

Inget av detta gör appen trasig. Allt av det får en riktig terapeut att tänka: “Det här känns som något jag slängde ihop på en helg, inte något någon tar betalt av mig för.”

Den känslan är verklig, och den spelar roll. En prototyp löser problemet i teorin. En produkt löser det i praktiken, för den faktiska människan som använder den.

Tre frågor som skiljer prototyp från produkt

Här är den svåra delen: du kan inte veta allt som saknas. Din AI-byggare kan inte heller veta det. Så du behöver tre snabba frågor för att lista ut vilken sida av linjen du är på.

1. Skulle du använda det här för att lösa ditt eget problem?

Den här är ärlig, för du måste faktiskt leva med din egen produkt.

Om du är grundaren av den där bokningsappen för terapeuter, skulle du använda den för att boka dina egna terapitider? Inte “skulle du kunna” — skulle du faktiskt använda den istället för en mejlkedja eller ett delat Google-dokument?

Om svaret är nej är du inte klar. Du vet exakt vad som är fel — du känner det varje gång du öppnar appen. Om svaret är ja är du närmare.

Grundaren jag nämnde gick igenom sin egen terapeutregistrering. Hon fastnade vid formuläret (det frågade efter för mycket information innan det lät henne boka). Hon såg bekräftelsemejlet och tyckte det såg amatörmässigt ut. Hon började fundera på hur hennes terapeut skulle ta emot mejlet och om det skulle hamna i skräpposten.

Hon använde inte sin egen produkt så som en betalande kund skulle. När hon gjorde det hittade hon tio saker att fixa.

2. Har du visat det för tre personer som inte är du?

Att prata med potentiella användare är svårare än att bygga, och de flesta grundare hoppar över det för att de vill överraska folk vid lansering. Det är ett misstag.

Du behöver ingen fokusgrupp. Du behöver tre personer som liknar den du tror är din kund. För terapeutappen är det tre faktiska terapeuter.

Här är vad du letar efter: var blir de förvirrade? Var tvekar de? Vad frågar de om? Inte “vad tycker de om det?” (folk är för snälla). Be dem faktiskt göra grejen — boka en tid, skicka ett bekräftelsemejl, avboka något.

När grundaren visade sin terapeutapp för tre terapeuter frågade två av dem: “Kan jag sätta regler för när jag är tillgänglig? Typ, jag tar bara nya klienter på torsdagar, och jag dubbelbokar inte före kl. 14.” Appen hade en kalender, men inga regler. Hon hade byggt prototypen för hur hon trodde att schemaläggning fungerade, inte hur terapeuter faktiskt jobbar.

Det är produktinformation. Du kunde inte gissa det från en specifikation.

3. Vad skulle gå sönder om du gav det här till tio riktiga användare?

Det här är den svåraste frågan för den kräver att du verkligen tänker på dina specialfall.

För terapeutappen:

Vad händer om en klient försöker boka två tider samtidigt? (Appen kollar inte.)
Vad händer om en terapeut avbokar en tid? Får klienter en notis automatiskt? (Nej.)
Vad om en klients mejladress är fel? Finns det ett sätt att fixa det utan att börja om? (Nej.)
Vad om en terapeut har en sjukdag och behöver stänga sin kalender i en vecka? (Hon skulle behöva radera varje tid manuellt.)

Det här är inte buggar. Appen kraschar inte. Men de är pappersskärsår. Med tio riktiga användare och riktiga specialfall stöter du på alla i första veckan.

En produkt hanterar specialfallen. Inte alla — vissa saker kan vänta. Men de som händer de första två veckorna med riktiga användare, de behöver fungera.

Hur du bestämmer dig: tre-lagers-testet

Använd det här för att lista ut var du är:

Lager 1: Kärnflöde — Fungerar lyckovägen? Kan en användare göra huvudgrejen din app är designad för?

För terapeutbokningen: ja. Någon kan registrera sig, boka en tid, få en bekräftelse. Det fungerar.

Lager 2: Specialfall från verklig användning — Du har visat det för tre faktiska användare. Stötte de på något du inte byggde för? Blev de förvirrade någonstans?

För terapeutbokningen: ja. De tre terapeuterna ville ha regelbaserad tillgänglighet. En blev förvirrad för att mejlbekräftelsen såg för generisk ut. En försökte massradera tider och kunde inte.

Lager 3: Polering och professionalitet — Känns det som att du bryr dig? Eller känns det som att du slängde ihop det?

För terapeutbokningen: det känns ihopslängt. Mejlbekräftelserna är spartanska. Det finns ingen egen varumärkning. Det finns inget felmeddelande om något går fel, så om något går sönder har användaren ingen aning om vad som hände.

Här är tumregeln:

Alla tre lager fungerar? Du är en produkt. Lansera den.
Lager 1 och 2, inte 3? Du är 80 % klar. Lägg en dag på polering.
Lager 1 fungerar, lager 2 och 3 inte? Du är en prototyp. Lansera inte än.
Lager 1 är inte solitt? Du är inte klar. Fortsätt bygga.

Terapeutappen fastnade vid gränsen mellan lager 1 och lager 2. Kärnflödet fungerade, men riktiga terapeuter tyckte att det saknade delar. Så grundaren hade ett val: lägga ytterligare en vecka med sin AI-byggare på att lägga till funktionerna terapeuter faktiskt behöver, eller lansera med det hon hade och lägga till dem senare.

(Hon lade till dem. Det tog tre dagar. Nu är den en produkt.)

Grejen som gör det här svårt

Anledningen till att så många grundare fastnar här är att det är kul att bygga och skrämmande att leverera.

Att bygga är en konversation med ditt AI-verktyg. Du har en idé, du beskriver den, verktyget verkställer den. Det finns en återkopplingsloop som tar minuter. Att leverera är annorlunda. Du trycker på publicera, och om något är fel får riktiga människor reda på det. Det finns inget omtag.

Så vi hittar anledningar att inte leverera. “Den är inte tillräckligt polerad.” “Jag borde lägga till en funktion till.” “Tänk om typsnitten är fel?” Och sex veckor senare sitter du fortfarande på något som fungerar men inte känns klart, och du har övertygat dig själv om att det är på grund av typsnitten.

Det är inte typsnitten.

Det är oftast att du inte har spenderat tid med en riktig användare, eller att du har byggt något som var vettigt i ditt huvud men inte riktigt passar hur riktiga människor jobbar. Det går att fixa. Det kräver bara att du erkänner att du inte vet vad du inte vet, och sedan går och pratar med någon som gör det.

Checklistan för lanseringsredo

Använd den här. Den är kort och ärlig.

Jag har själv använt den för att göra den riktiga uppgiften, och den fungerade (inte på ett demoläge-sätt, utan på riktigt).
Jag har visat den för tre personer som faktiskt skulle använda den, och jag har fixat sakerna de var förvirrade över.
Varje fel som kan inträffa har ett meddelande som berättar för användaren vad de ska göra åt det (inte “fel”, utan faktisk vägledning).
Jag skulle vara okej om det här var den sista versionen i sex månader (innebörd: den är komplett nog att vara användbar även om jag aldrig rör den igen).
Jag är mer exalterad över vad jag kommer lära mig av riktiga användare än jag är över att lägga till fler funktioner i ett vakuum.

Om du kan bocka av alla fem rutor är du klar. Lansera.

Om du inte kan det, gör det inte. Men var specifik om varför. “Den känns inte klar” är inte en anledning. “Riktiga terapeuter behöver tillgänglighetsregler och det har jag inte byggt än” är en anledning. Det är åtgärdbart. Det går att fixa. Det är skillnaden mellan att vara fast och att vara på en väg.

Grundaren av terapeutappen lanserade den igår. Hon har sin första betalande kund. Produkten är inte perfekt, men den är riktig, och hennes kund berättar redan för henne vad hon ska bygga härnäst. Det är då du vet att du är klar: inte när appen är perfekt, utan när du är redo att lära dig vad perfekt faktiskt betyder för de som använder den.