Figma-prototyp eller kodad MVP?
En Figma-prototyp kostar 50 000–150 000 kr och testar upplevelse, flöde och betalvilja i intervjuer. En kodad MVP kostar från cirka 300 000 kr och testar verkligt beteende: om användare kommer tillbaka och betalar på riktigt. Välj utifrån den största osäkerheten – ligger den i designen räcker prototypen, ligger den i affären eller tekniken krävs en MVP.
Både prototypen och MVP:n kallas “att testa idén” – men de bevisar helt olika saker. Att välja fel verktyg är dyrt åt båda hållen: en MVP för att svara på en fråga som en prototyp hade klarat kostar en kvarts miljon i onödan, och en prototyp där en MVP behövts ger falsk trygghet. Här är vad respektive verktyg faktiskt kan bevisa.
Vad en Figma-prototyp kan bevisa
En klickbar Figma-prototyp ser ut och känns som en riktig produkt, men är en serie hopkopplade skärmbilder. Den kostar 50 000–150 000 kr, tar ett par veckor att ta fram och kan ritas om mellan två intervjuer.
Den bevisar sådant som syns och upplevs: förstår användarna vad tjänsten gör? Hittar de genom flödet? Reagerar de på prissidan med intresse eller tvekan? I intervjuer ger den starka signaler om upplevelse, begriplighet och uttalad betalvilja. Det den inte kan bevisa är beteende över tid – ingen “använder” en prototyp på riktigt, och ingen betalar riktiga pengar i den.
Vad en kodad MVP kan bevisa
En MVP är en riktig, driftsatt produkt avgränsad till ett kärnflöde. Den kostar från cirka 300 000 kr och uppåt och tar åtta veckor eller mer att bygga.
Den bevisar det prototypen inte når: verkligt beteende. Kommer användarna tillbaka nästa vecka utan att någon intervjuar dem? Slutför de flödet när ingen tittar? Betalar de med eget kort? Fungerar tekniken mot riktiga data? Det är skillnaden mellan vad människor säger och vad de gör – och för affärsbeslut är det bara det senare som räknas.
Jämförelsen i korthet
| Fråga | Figma-prototyp | Kodad MVP |
|---|---|---|
| Kostnad | 50 000–150 000 kr | Från cirka 300 000 kr |
| Tid att ta fram | 2–4 veckor | 8–14 veckor |
| Bevisar | Upplevelse, flöde, uttalad betalvilja | Verkligt beteende, återkommande användning, riktig betalning |
| Testmiljö | Intervjuer och demos | Verklig användning i drift |
| Kostnad att ändra | Timmar | Dagar till veckor |
Beslutsregeln: var sitter din största osäkerhet?
Fråga dig vilken osäkerhet som skulle sänka satsningen om den föll åt fel håll – design, affär eller teknik:
- Design och begriplighet. “Kommer användarna att förstå och vilja ha det här?” Börja med prototypen. Den svarar på frågan för en tiondel av kostnaden och kan itereras tills svaret är tydligt.
- Affären. “Kommer folk att betala och återkomma?” Prototypen ger en första signal via intervjuer, men beviset kräver MVP – återkommande användning och riktiga betalningar går inte att simulera.
- Tekniken. “Går det att bygga – klarar vi datat, prestandan, integrationen?” Här hjälper ingen Figma i världen; det kräver kod. En teknisk proof of concept eller en MVP är rätt verktyg.
För de flesta nya tjänster är ordningen därför: prototyp först för att hitta rätt i upplevelsen billigt, sedan MVP på det validerade flödet för att testa affären på riktigt.
Räkneexempel: två vägar till samma svar
En grundare vill lansera en abonnemangstjänst. Väg A: bygga MVP direkt för 500 000 kr. Efter lansering visar det sig att onboardingen missförstås – ombyggnad för 150 000 kr och två månaders förlorad tid. Totalt 650 000 kr. Väg B: prototyp för 100 000 kr, tio intervjuer, två omritningar där onboardingproblemet upptäcks och löses – därefter MVP på det validerade flödet för 450 000 kr. Totalt 550 000 kr, snabbare till fungerande produkt och med betydligt lägre risk längs vägen.
Prototypen “kostade” alltså inte 100 000 kr – den sparade 100 000 kr och två månader. Så ser kalkylen ut i de flesta fall där osäkerheten i designen är stor.
Fällan åt båda hållen
Prototyper kan bli en flyktväg: en tjänst som demonstreras i evighet men aldrig möter verkligheten testar till slut ingenting. Och MVP:er som byggs för tidigt testar fel saker dyrt. Verktygen är steg i samma trappa – vi på Weapp använder normalt båda i följd som en del av våra tjänster, med ett tydligt beslut emellan. Osäker på var din idé står? Hör av dig så hjälper vi dig identifiera den största osäkerheten först.
Vanliga frågor
Kan designen från Figma-prototypen återanvändas när MVP:n byggs?
Ja, det är en av prototypens stora poänger. Flöden, skärmar och komponenter blir direkt underlag för utvecklingen, vilket kortar MVP:ns designfas rejält. Någon kod finns däremot inte att återanvända – prototypen är en bildserie som känns verklig, inte en produkt.
Kan en prototyp verkligen testa betalvilja?
Den kan testa uttalad betalvilja: visa en prissida i intervjun och be personen resonera, eller be om en avsiktsförklaring. Det är en stark signal men inte ett bevis – människor överskattar sin egen betalvilja i samtal. Verklig betalvilja kräver att riktiga pengar byter ägare, och det testar först MVP:n.
Hur många användartester behövs på en prototyp?
Fem till åtta intervjuer per runda brukar räcka för att tydliga mönster ska framträda – därefter ger fler intervjuer snabbt avtagande ny information. Styrkan i prototypen är att den kan ritas om mellan rundorna, så två eller tre korta rundor slår nästan alltid en stor.
Vad är skillnaden mot en proof of concept?
En proof of concept testar teknik: går det över huvud taget att bygga – klarar API:et, räcker prestandan, fungerar algoritmen? Den har oftast inget gränssnitt att visa användare. Prototypen testar upplevelsen, MVP:n testar affären i verklig användning – tre verktyg för tre olika osäkerheter.
Måste MVP:n byggas i samma teknik som den färdiga produkten?
Helst ja. En MVP byggd i en stack som bär vidare kan vidareutvecklas till produkten, medan en MVP i tillfällig teknik måste skrivas om efter valideringen – då betalar du för samma sak två gånger. Undantaget är rena engångsexperiment som medvetet ska slängas.