MVP eller prototyp – vad är skillnaden?
En prototyp simulerar produkten: den ser äkta ut men fungerar inte på riktigt, och testas i intervjuer. En MVP fungerar faktiskt och möter riktiga användare i drift. Därför kostar en MVP ofta omkring tio gånger mer. Prototypen svarar på om folk förstår idén, MVP:n på om de använder och betalar.
“Vi ska bygga en prototyp” och “vi ska bygga en MVP” sägs som om de vore samma sak – och blandas ihop i nästan varje uppstartsmöte. Men de bevisar olika saker och skiljer sig kraftigt i pris. Kortfattat: en prototyp simulerar produkten, medan en MVP fungerar på riktigt. Att välja fel av dem kostar antingen pengar i onödan eller ger falsk trygghet. Här är skillnaden som avgör budgeten.
Prototypen simulerar – MVP:n fungerar
En prototyp är en trovärdig attrapp. Den ser ut och känns som produkten, men under ytan finns ingen riktig logik – klickar du på en knapp hoppar du till nästa förberedda skärm, inget beräknas eller sparas. Den lever i intervjuer och demos, där en testperson kan reagera på den som om den vore verklig.
En MVP är motsatsen: en riktig, driftsatt produkt, om än avskalad till sitt kärnflöde. Den har kod, databas, konton och ofta betalningar. Riktiga användare kan använda den utan att någon står bredvid och förklarar, och det de gör är verkligt beteende, inte reaktioner i en intervju.
Skillnaden är alltså inte hur färdiga de ser ut – båda kan se polerade ut – utan om det finns något som fungerar bakom ytan.
Därför skiljer kostnaden ofta tiofaldigt
Att en MVP kan kosta i storleksordningen tio gånger mer än en prototyp förvånar många, men följer direkt av skillnaden ovan. En attrapp kräver design och länkade skärmar. En fungerande produkt kräver dessutom allt det osynliga: logik, datalagring, konton, säkerhet, betalningar och drift.
| Aspekt | Prototyp | MVP |
|---|---|---|
| Vad den är | Simulering, länkade skärmbilder | Fungerande, driftsatt produkt |
| Bevisar | Förståelse, flöde, uttalad vilja | Verkligt beteende, användning, betalning |
| Testas i | Intervjuer och demos | Verklig användning i drift |
| Relativ kostnad | Lägst | Ofta cirka tio gånger högre |
| Ändras på | Timmar | Dagar till veckor |
Den tiofaldiga skillnaden är alltså inte ett påslag – den speglar att du får två väsensskilda saker. Och den är motiverad, eftersom en MVP svarar på frågor en prototyp aldrig kan nå: kommer folk tillbaka, slutför de flödet på egen hand, betalar de med riktiga pengar?
Ordningen: prototyp före MVP – och när steget hoppas över
För en ny produkt med osäker design är den logiska ordningen prototyp först, MVP sedan. Prototypen låter dig hitta rätt i upplevelsen billigt och snabbt, med skärmar som kan ritas om mellan intervjuer tills flödet sitter. Den valideringen tas sedan vidare in i MVP:n, som testar affären på riktigt – och prototypens skärmar blir dessutom underlag som kortar MVP:ns designfas.
Men steget hoppas ibland över med gott samvete. Är flödet enkelt och välkänt, eller finns redan ett beprövat mönster att följa, tillför prototypen lite och du kan gå direkt på MVP. Sitter osäkerheten enbart i tekniken snarare än i upplevelsen är det inte heller en prototyp du behöver, utan ett tekniskt test.
Ett konkret scenario
Ett team ville bygga en tjänst med ett nytt sätt att navigera bland innehåll. Utan prototyp: de bygger MVP direkt för 500 000 kr, lanserar, och upptäcker att användarna inte begriper navigeringen. Ombyggnad och förlorad tid följer.
Med prototyp: de tar först fram en prototyp för runt 80 000 kr, testar den på åtta personer och ser genast att navigeringen förvirrar. Två omritningar senare är flödet begripligt – och först då byggs MVP:n, på ett upplägg som redan visat sig fungera. Prototypen kostade inte 80 000 kr; den räddade en betydligt större summa och veckor av tid. Så ser kalkylen ut när designosäkerheten är stor.
Den vanliga hopblandningen och vad den kostar
Priset för att förväxla begreppen betalas åt båda håll. Beställer du en “prototyp” men menar en produkt som ska klara riktiga användare, blir du besviken när attrappen inte kan driftsättas – den var aldrig byggd för det. Beställer du en “MVP” men egentligen bara vill testa om folk förstår idén, betalar du för kod och drift när länkade skärmar hade räckt.
Missförståndet uppstår för att båda orden i vardagsspråk betyder ungefär “en tidig, enkel version”. Men de skiljer sig i det som kostar: om det finns något som fungerar bakom ytan. Att reda ut vilket av de två du faktiskt behöver, redan innan du ber om en offert, är därför ett av de billigaste besluten i hela projektet – och ett av de mest kostsamma att slarva med.
Osäker på vilket steg just din idé behöver? Vi på Weapp reder ut var osäkerheten sitter innan något byggs, som en del av våra tjänster. Hör av dig med din idé så pekar vi ut rätt startpunkt.
Vanliga frågor
Kan man hoppa direkt till en MVP utan prototyp?
Ja, om osäkerheten inte sitter i designen. Är flödet enkelt och välkänt, eller finns redan ett beprövat gränssnitt att luta sig mot, tillför en prototyp lite. Sitter osäkerheten däremot i om användarna förstår och vill ha upplägget, sparar prototypen pengar genom att fånga missförstånden innan de byggs i kod.
Varför kostar en MVP så mycket mer än en prototyp?
För att den faktiskt fungerar. En prototyp är hopkopplade skärmbilder utan logik under ytan. En MVP har riktig kod, databas, konton, betalningar och drift – allt som krävs för att verkliga användare ska kunna använda den på riktigt. Det är skillnaden mellan en attrapp och en produkt, och därav storleksskillnaden i pris.
Är prototypen bortkastade pengar om vi ändå ska bygga en MVP?
Nej, tvärtom. Prototypen brukar spara pengar totalt sett genom att missförstånd rättas när de bara kostar timmar, inte veckor av utveckling. Dessutom blir prototypens skärmar och flöden direkt underlag för MVP:n, vilket kortar dess designfas. Det du inte kan återanvända är kod – någon sådan finns inte i en prototyp.
Vad ska prototypen innehålla för att vara användbar?
De skärmar och flöden som bär den viktigaste hypotesen, tillräckligt verkligt utformade för att en testperson ska glömma att det är en attrapp. Den behöver inte täcka alla fall – bara den väg där du är mest osäker på om användaren förstår och vill gå vidare. Resten är utfyllnad som fördröjer testet.
Hur många steg finns det mellan idé och färdig produkt?
Ofta tre: prototyp för att testa upplevelsen, MVP för att testa affären i verklig användning, och därefter utbyggnad mot färdig produkt. Man behöver sällan alla tre – vilka steg som krävs styrs av var osäkerheten sitter. Prototyp och MVP löser olika problem och ska inte förväxlas.