Från idé till intäkt: den minsta funktionsdugliga produkten du kan bygga med AI

Det gamla sättet fungerar inte längre

För fem år sedan var startup-spelplanen: välj en idé, lägg tre månader på att bygga MVP:n, lansera till tystnad, iterera.

Det var när “MVP” betydde “alla grundfunktioner, superpolerat, redo för en väntelista”.

Med AI-appbyggare som Proyecta ser tidslinjen annorlunda ut. Du kan ha något riktigt – inte en landningssida, inte en mockup, utan en faktiskt fungerande produkt – till lunch imorgon. Men nästan ingen vet hur man ska tänka kring vad “minsta” faktiskt betyder när man bygger med AI.

Det här är vad jag ser: de flesta lanserar alldeles för mycket. De lägger till en instrumentpanel, användarkonton, integrationer, analys, kanske en mobilappversion. Sedan använder ingen den, eftersom de optimerade för fullständighet – bockade av rutor – i stället för att lösa ett specifikt problem för en specifik person, just nu.

Vad minsta faktiskt betyder nu

Den minsta funktionsdugliga produkten med AI är så liten att det nästan är roligt. Den är:

Ett arbetsflöde. Inte fem funktioner. En sak din målperson gör upprepade gånger som idag tar 10 minuter, och din app kapar den till 30 sekunder.

Inga konton. Om du kan skeppa det utan inloggning – gör det. En person, en session, ett resultat. Om de gillar det kan du lägga till konton senare. Stripe-inloggningsflöden tar 20 minuter att implementera ordentligt. Engångssessioner tar fem.

Ingen databas. Åtminstone inte en du hanterar. Lägg din data i ett Google Sheet. Använd localStorage i webbläsaren. Använd Stripe eller Airtable som din backend. Du försöker hitta kunder, inte bygga infrastruktur.

En integration. Välj det enda verktyg din kund redan använder och integrera med det. “Fungerar med Slack” eller “läser från din Google Drive” är mycket mer användbart än “har sitt eget arkiveringssystem”.

Här är ett konkret exempel: Sarah byggde ett verktyg för frilansande designers som lägger en evighet på att förklara sin stil för nya kunder. Hennes app: du laddar upp tre av dina bästa designer, beskriver din process på vanlig svenska, och appen genererar en “stilguide” som PDF som designern kan skicka till kunder. Det är allt. Inga konton, ingen inloggning, ingen instrumentpanel. Varje gång någon använder den börjar de från noll. Appen körs i Proyecta, hon använder Stripe för betalningar (den genererar en engångslänk per PDF), och när folk ber om fler funktioner (som “spara flera stilar”) kanske hon lägger till det – eller så inser hon att hennes riktiga produkt inte är appen, utan att sälja dessa som mallar.

Hon tjänade 600 dollar den första veckan.

De tre mätvärden som faktiskt spelar roll

Mät inte fullständighet. Mät inte tid-på-sida. Mät dessa tre:

Tid till första värdet. Från “jag hittade den här länken” till “jag fick ett resultat jag faktiskt kan använda”. För Sarahs verktyg: 90 sekunder. Om det tar mer än fem minuter faller folk av.
Betalningsvilja. Lansera inte med en gratisnivå och en Pro-nivå. Välj ett pris. Se om folk vill betala det. (25 dollar för Sarahs PDF:er. Hon skulle kunna ta mer; hon tar mindre för att hon bara vill validera.) Om svaret är “aldrig i livet” valde du fel problem.
Kommer-de-tillbaka-grad. För ett engångsverktyg behöver du ingen 30-dagars retention. Du behöver veta: av de som använde det en gång, hur många berättar för en vän? Sarahs retention-mätvärde är “berättade för minst en annan designer”. Det är 40 % hittills.

Om alla tre är bra har du något. Nu kan du lägga till konton, instrumentpaneler, historik, allt det där.

Så lanserar du på en helg

Fredag morgon: Välj ditt problem. Inte en marknad. Inte en trend. En specifik person som gör en specifik sak som är irriterande idag.

Fredag eftermiddag–lördag morgon: Använd Proyecta för att bygga det. Du beskriver vad du vill ha (“ta ett PDF-kontrakt och markera alla betalningsvillkor i rött”), Proyecta genererar det, du testar det, justerar det tills det fungerar. Fyra timmar, kanske sex om du är kräsen. Du har nu en fungerande webbapp.

Lördag eftermiddag: Testa det på två personer. Inte “hej, skulle du använda det här i teorin?” utan “här är länken, använd den på riktigt, och berätta vad som gick sönder eller kändes konstigt”.

Söndag morgon: Sätt upp betalning om du tar betalt. Stripe, Gumroad, en enkel länk – du bygger inte en faktureringsplattform. Bara ett sätt att ta betalt.

Söndag kväll: Skeppa det. Posta till Show HN, en relevant Discord eller Slack, mejla fem personer direkt. Plåga dig inte med beskrivningen. Inled med varför du byggde det: “Jag gjorde det här för att jag var frustrerad över att …”

Måndag: Se vad som faktiskt händer. Riktiga människor använder det eller inte. Du vet inom 48 timmar.

Vad som händer sedan (den enkla delen)

Om ingen använder det: du lärde dig något snabbt och billigt. Du pivoterade till tisdagen.

Om några använder det: du tittar på vad de faktiskt gör med det. Använder de det exakt som du designade det, eller gör de något lite annorlunda? Ber de om funktioner du inte förväntade dig, eller använder de det bara tyst och går vidare?

Om folk använder det, ber om saker, och du är säker på att du vill jobba med detta: då kan du investera i ordentliga grejer. Konton, så folk kan spara sitt arbete. En instrumentpanel, så de kan se vad de byggt. Ett API, om det är vad de behöver. Men du bygger de här funktionerna för att du vet att det finns efterfrågan, inte för att du tror att de borde existera.

Det största misstaget är att skeppa med antagandet att din idé är rätt och att ditt enda jobb är att övertyga folk om det. Den minsta funktionsdugliga produkten är det första testet av det antagandet. Allt efter det är bara att lyssna.

Tre riktiga historier

Marcus (dataanalytiker): Lade en timme varje vecka på att manuellt formatera om SQL-frågor åt junioranalytiker. Byggde ett verktyg i Proyecta som gör det med ett klick: klistra in fråga, få formaterad version. Ett inmatningsfält, en knapp. Lanserade det en tisdag. Till fredagen hade han 300 användningar från folk i sin Discord. Vid månadsskiftet: 1 200 användningar, en del från totala främlingar. Han lade till konton så folk kunde se sin historik, sedan byggde han en integration med sitt datalager. Det är nu hans andra inkomst.

Jade (illustratör): Gjorde ett verktyg som tar en röstanteckning och genererar en karaktärsskiss baserad på beskrivningen. Lade 45 minuter på att bygga det. Tog 3 dollar per skiss. Tjänade 1 500 dollar de första två veckorna innan hon pausade det, eftersom hon fick så många beställningar att hon inte hann med affärsadministrationen.

Omar (grundare): Ville bygga en “komplett plattform”. Lade två månader. Lanserade med konton, prisnivåer, integrationer med tre verktyg och en instruktionsvideo. Tre månader senare: 12 användare, två av dem var hans vänner. Han insåg att han hade optimerat för lansering i stället för för lärande. Hans omstart är mycket mindre – bara kärnarbetsflödet – och han får riktigt fäste.

Det ingen berättar för dig

Att skeppa litet är skrämmande för att det känns ofullständigt. Din hjärna skriker “men vi måste hantera [specialfall], hur är det med [funktion], borde vi inte [lägga till komplexitet]?”

Nej. Skeppa det ändå.

Ditt jobb är inte att bygga den perfekta produkten. Ditt jobb är att testa det minsta vad som bevisar att du löser ett riktigt problem för en riktig person. Allt efter det är bara att lyssna och iterera baserat på vad som är verkligt.

Vad skulle du kunna bygga i helgen med en AI-appbyggare? Något pyttelitet. Något du själv skulle använda. Prova och se.