AFP istället för MVP: när bygget blir så billigt att minimering blir ett hinder

Om vad som händer med en av produktutvecklingens heligaste doktriner när en kapabel kodmodell kan bygga hela produkten på en gång, och varför jag bytte ut MVP mot något jag kallar Absolute Functional Product

Jag satt mitt i ett bygge när tanken slog mig.

Jag höll på att ta fram en kravspecifikation, en PRD, tillsammans med Claude för en SaaS-produkt som ska hjälpa svenska små och medelstora företag att hantera efterlevnad av EU:s AI Act. Förarbetet var redan gjort, och det var omfattande. Ett halvårs tänkande låg bakom. Produktdefinitionen var genomarbetad, datamodellen spikad, lagstiftningen verifierad, designsystemet färdigt. Jag hade också gjort min marknadsundersökning. Jag visste vem målgruppen var, jag hade tagit reda på vad den faktiskt efterfrågade, och jag visste att köpviljan fanns där. Jag visste exakt vad produkten skulle vara, och jag visste att det fanns någon som ville ha den. Det fanns ingenting kvar att gissa.

Och ändå föreslog rådgivaren, en AI, det helt självklara: börja med en MVP. Bygg det minsta möjliga som går att testa, släpp det, lär dig av marknaden, iterera fram resten. Det är rätt råd nio gånger av tio. Det är så vi alla har lärt oss att bygga i över ett decennium. Men just där, just då, kände jag att det var fel.

För vad fanns det att lära sig av en avskalad version, när jag redan visste vad produkten skulle göra? Och varför skulle jag bygga en kastrerad variant för att sedan iterera upp den till det jag redan hade i huvudet, när modellen framför mig kunde bygga hela den fungerande produkten på en gång?

Det vore som att springa ett halvmaraton bara för att sedan springa hela vägen igen.

Så jag myntade ett motbegrepp. Inte Minimum Viable Product, utan Absolute Functional Product. AFP. Inte den minsta livskraftiga, utan den fullständigt fungerande, byggd i ett svep, redo att säljas som den är.

Premissen som ingen längre ifrågasätter

MVP vilar på ett antagande som sällan sägs högt: att det är dyrt och långsamt att bygga. Hela logiken följer av det. Eftersom bygget kostar mycket i tid och pengar måste du minimera insatsen innan du vet om något fungerar. Du bygger det minsta tänkbara, kastar ut det, och låter marknaden tala om för dig om det är värt att bygga vidare.

Det är en sund logik. Den har räddat oändligt många entreprenörer från att lägga ett år på något ingen ville ha. Men den är en artefakt av en viss kostnadsstruktur. Och den kostnadsstrukturen håller på att vittra sönder.

När en kapabel modell kan bygga en komplett, fungerande produkt på timmar istället för månader, försvinner en stor del av skälet att avgränsa sig till ett minimum. Då är frågan inte längre hur lite du kan komma undan med att bygga. Frågan blir varför du överhuvudtaget skulle bygga mindre än hela grejen.

Många kallar det här att one-shota. Du skriver en så omfattande och genomtänkt PRD att den beskriver allt produkten ska göra, matar in den, och får ut en färdig produkt. Inte en skiss, inte en testballong, utan något som faktiskt levererar värdet och går att ta betalt för.

Verktyget som flyttade tröskeln

Det här är inte en abstrakt tanke. Den blev möjlig för mig av ett konkret verktyg, vid en konkret tidpunkt.

Jag arbetar med Claude Code på Opus 4.8, Anthropics mest kapabla publika modell, som släpptes i slutet av maj 2026. För den som inte följer detaljerna kan det låta som en marginell versionsbump, men i praktiken är det ett verktyg av ett annat slag än vad vi hade för bara några månader sedan. Modellen är byggd för långa, agentiska kodningsuppdrag. Den kan hantera väldigt mycket kontext på en gång, den följer instruktioner med en konsekvens som tidigare modeller saknade, och den flaggar själv när något i underlaget är oklart eller motsägelsefullt i stället för att gissa och köra vidare.

Anthropic uppger att den är ungefär fyra gånger mindre benägen än föregångaren att låta brister i sin egen kod passera oanmärkta. Det är just den egenskapen som gör skillnaden för en AFP-strategi. När du bygger allt på en gång är felkorrigeringen inte längre marknaden, den måste finnas i modellen och i din egen granskning.

Default-läget heter high, och för riktigt tunga uppdrag finns ett högre läge som i Claude Code kallas xhigh, där modellen lägger mer beräkning på att få det rätt. Det är i det läget en ambitiös PRD förvandlas till en färdig produkt snarare än till en prototyp som behöver byggas om.

Poängen är inte att hylla en specifik modell. Poängen är att tröskeln för när minimering lönar sig har flyttat sig, och att den fortsätter flytta sig. Ju mer kapabelt verktyget blir, desto mer lutar valet mot AFP.

När AFP gäller, och när det inte gör det

Jag vill vara tydlig med en sak, för annars blir det här bara hype. MVP är inte dött. Påståendet är inte att du alltid ska bygga allt på en gång. Påståendet är att valet mellan MVP och AFP nu beror på tre saker, och att du behöver väga dem medvetet i stället för att reflexmässigt välja minimum.

Det första är hur kapabel modellen är för just din uppgift. En enkel app i ett väldokumenterat ramverk ligger inom räckhåll för en AFP idag. Något exotiskt, med tunna träningsdata och hög komplexitet, gör det inte med samma säkerhet. Ju mer kapabel modellen är för din specifika sak, desto mer lutar det mot AFP.

Det andra är hur genomtänkt idén redan är. Det här är den avgörande punkten. Om förarbetet är gjort, om du vet vad produkten ska vara, och om du redan har tagit reda på att målgruppen vill ha den, då finns det ingenting kvar att lära sig genom en avskalad version. Då rättfärdigar inget minimeringen. Men om idén fortfarande är oklar, om du inte ens vet om någon är beredd att betala för det här, då är MVP fortfarande rätt. Då behöver du marknadens svar, och då lär du dig något av att släppa något litet. Det är just därför AFP förutsätter att du har gjort din marknadsundersökning i förväg. Du flyttar inte in i ett fullskaligt bygge i blindo, du gör det för att du redan vet att köpviljan finns där.

Det tredje är vad bygget faktiskt kostar dig. När det kostar lite i tid och pengar att bygga hela produkten, blir det inte längre särskilt riskabelt att bygga för mycket, samtidigt som värdet av att ha en komplett produkt på plats är stort. Det är den enkla kalkylen som vänder. När bygget var dyrt straffades du hårt för att bygga fel saker. När bygget är billigt blir det misstaget billigt, och vinsten av att ha allt klart direkt blir desto större.

Priset för hastigheten

Men AFP har en verklig fallgrop, och jag gick rakt i den.

När du bygger allt på en gång är det lättare att bygga åt fel håll i tysthet. Det finns ingen tidig användare som korrigerar dig. Minimeringen i MVP är nämligen inte bara en kostnadsgrej, den är också en felkorrigeringsmekanism. Varje liten release tvingar fram en konfrontation med verkligheten.

I mitt eget bygge hände precis det. En central egenskap i produkten, att dokumentgenereringen skulle vara AI-driven, blev feltolkad. Modellen började bygga den delen fel, och eftersom jag byggde allt på en gång fanns det ingen extern signal som ropade stopp. Jag fångade felet, men jag fångade det genom granskning, inte genom att en användare sa ifrån.

Det är priset för hastigheten. Bygger du en AFP måste du ersätta MVP:ns inbyggda felkorrigering med två andra saker: en osedvanligt tydlig specifikation, och löpande granskning längs vägen. Du flyttar felkorrigeringen från användarna in i ditt eget arbete. Om du inte gör det bygger du fel, fast snabbare.

Att stanna upp blev till slut ett hinder

Maxwell Maltz beskrev i Psycho-Cybernetics sinnet som en målsökande mekanism. Du sätter ett mål, gör ett försök, får feedback, korrigerar kursen, gör ett nytt försök. Framgång nås genom att träffa målet efter missade skott. Du måste vara villig att missa, och du måste ha en återkopplingsslinga.

MVP är den principen gjuten i metod. Bygg lite, mät, korrigera, bygg lite till. Stanna upp, justera, fortsätt. I årtionden har det varit den rationella vägen, just för att varje steg var dyrt och därför var värt att granska innan nästa steg togs.

Men jag har märkt något. När verktygen blir tillräckligt skickliga kan det ständiga stannandet och korrigerandet faktiskt bromsa mig. När jag redan vet i mitt huvud vart jag ska, blir den lilla, försiktiga, ständigt korrigerande rörelsen ett hinder snarare än en hjälp. Jag hamnar i att förvalta en process som var byggd för en kostnad jag inte längre har.

Den verkliga självkorrigeringen, i Maltz egen anda, var att märka det. Att se att MVP-tänket saktade ner mig, och att justera kursen. Inte korrigera produkten i hundra små steg, utan korrigera mitt eget sätt att arbeta. Låta verktyget bygga hela den fungerande produkten, och sedan gå in och målsöka, iterera och förändra därifrån, nu med riktiga användare. Återkopplingsslingan finns kvar. Den har bara flyttat. Den börjar inte längre vid en avskalad skiss, den börjar vid en färdig produkt.

Modet att säga: bygg hela skiten

Det finns något nästan obekvämt i att gå emot ett råd som är så rätt så ofta. Att börja smått är klok ödmjukhet, och den klokskapen sitter djupt. Att i stället säga nej, bygg allt, känns nästan oansvarigt, ett eko av det gamla varnande ordet om att inte bygga för mycket innan du vet.

Men det rådet var sant i en värld där bygget var dyrt. När den premissen faller, faller också mycket av det vi tar för givet i produktutveckling. En stor del av vad vi kallar best practice är egentligen artefakter av gamla kostnadsstrukturer, fossiler från en tid då koden var det dyraste i ekvationen.

Det nya entreprenörskapet i AI-eran handlar inte om att ha de bästa verktygen. Alla får snart tillgång till ungefär samma verktyg. Det handlar om att ha klarheten att veta vad du vill bygga, och modet att låta verktyget bygga hela den fungerande produkten direkt, med disciplinen att granska den ordentligt längs vägen.

MVP frågade: vad är det minsta jag kan komma undan med? AFP frågar något annat: jag vet vad det här ska vara, så varför skulle jag bygga något mindre?

Källor och vidare läsning

Anthropic. (2026). Introducing Claude Opus 4.8.

Maltz, M. (1960). Psycho-Cybernetics.

Birgir Birgisson (2026). Vibe Coding Boken, Amazon, fördjupar tankarna om AI-assisterat byggande och vibe coding som AFP-resonemanget bygger vidare på.

Birgir Birgisson, Vibe Coding och enmansföretagets revolution tidigare artikel som tecknar det bredare sammanhanget kring AI-stödd byggande och soloentreprenörskap där AFP-tänket hör hemma.

Birgir Birgisson är AI-arkitekt, systembyggare och skribent med en Jungiansk och etisk kompass. Han bygger AI-drivna system och verktyg, och skriver om teknikens påverkan på människan, ledarskap och personlig utveckling. Delar av materialet kan vara framtaget eller skapat med hjälp av olika AI-verktyg.