Prototyp, proof of concept eller MVP?
Av CodexierPublicerad 4 min läsning
Grundare ber ofta om en MVP när de egentligen behöver en prototyp, eller betalar för en prototyp när den verkliga risken är teknisk. Orden används som om de betydde samma sak, men var och en besvarar en egen fråga. Definiera dem utifrån frågan så blir valet mycket enklare: du betalar för svaret du behöver nu, inte för det som ser mest färdigt ut.
Prototyp: förstår användarna?
En prototyp är en klickbar modell av produkten, oftast gjord i Figma. Den ser tillräckligt verklig ut för att testas, men det finns ingen fungerande backend: inga konton, ingen data, inga betalningar. Uppgiften är att visa idén för fem till åtta användare i målgruppen och se var de tvekar, missförstår eller tappar intresset.
Den är billig att ändra, och det är hela poängen. Att flytta ett steg i en prototyp tar minuter; att flytta det i färdig mjukvara tar dagar. Guiden om att testa en prototyp innan koden skrivs visar hur testerna går till.
Proof of concept: går det att bygga?
En proof of concept är ett smalt tekniskt experiment. Den saknar finputsad design och ofta helt gränssnitt. Den finns för att testa det enda som kanske inte fungerar: en integration mot ett system med dåligt API, en AI-modell som ska plocka ut data ur röriga PDF:er eller en realtidsfunktion som måste gå tillräckligt snabbt.
- Värd att göra när en teknisk osäkerhet kan fälla hela projektet
- Avgränsad till en fråga med ett ja- eller nej-svar
- Koden slängs eller skrivs oftast om kraftigt efteråt
- Inget att visa för kunder
MVP: använder och betalar folk?
En minsta livskraftiga produkt är riktig mjukvara som riktiga kunder använder för en riktig uppgift. Den måste fungera stabilt, hantera deras data säkert och, för en betald produkt, ta betalt. ”Minsta” handlar om omfattning, inte kvalitet: färre funktioner, var och en ordentligt gjord.
En MVP är dyrast av de tre eftersom den måste klara mötet med användarna: inloggning, säkerhet, GDPR, felhantering, drift och support. Förklaringen av vad en MVP är och inte är tar upp omfångsfällan närmare.
Kostnad och tid jämförda
| Aspekt | Prototyp | Proof of concept | MVP |
|---|---|---|---|
| Fråga | Förstår användarna? | Går det att bygga? | Använder och betalar folk? |
| Typisk tid | 1–3 veckor | 1–4 veckor | 2–4 månader |
| Vilka som deltar | Designer, grundare, testanvändare | Utvecklare, grundare | Designer, utvecklare, grundare, tidiga kunder |
| Vad du behåller | Design och testresultat | Ett tekniskt svar | En fungerande produkt |
| Relativ kostnad | Låg | Låg till medel | Högst |
Tiderna varierar med omfattningen; det är storleksordningen mellan de tre som spelar roll.
Hos oss täcker en designsprint vägen via prototyp och test, en MVP-planering avgränsar bygget och pekar ut de tekniska riskerna, och MVP-utvecklingen bygger produkten. Aktuella priser finns på prissidan.
Välj nästa steg
Rangordna riskerna ärligt. Är du osäker på om någon vill ha det, testa efterfrågan först, ibland med inget mer än en landningssida och samtal. Är du säker på efterfrågan men osäker på om användarna förstår lösningen, gör en prototyp. Kan en teknisk del fallera, gör en proof of concept. Bygg MVP:n när den kvarvarande risken främst är om folk fortsätter använda och betala.
| Ditt största tvivel | Nästa steg |
|---|---|
| Vill någon ha det här? | Kundintervjuer och en enkel landningssida |
| Förstår de hur man använder det? | Prototyp och användartester |
| Fungerar den svåra delen? | Proof of concept |
| Betalar de och kommer tillbaka? | MVP med en liten grupp tidiga kunder |
När du inte behöver någon av dem
Gör ett befintligt verktyg redan jobbet för dina första kunder, sälj tjänsten manuellt ovanpå det innan du bygger något. Ett kalkylark, ett formulär och mycket personlig uppmärksamhet kan validera en affärsmodell förvånansvärt långt. Är det det ärliga svaret säger vi det. När du är redo att prata om att bygga, boka ett kort samtal och ta med ditt mest riskabla antagande.
Vanliga frågor
Kan en prototyp bli MVP:n?
Designen kan följa med, och det sparar tid. Själva prototypen saknar fungerande backend, så MVP:n byggs ordentligt under den.
Är en proof of concept samma sak som en pilot?
Nej. En proof of concept testar teknisk genomförbarhet, oftast utan kunder. En pilot kör en fungerande lösning hos en riktig kund under en begränsad tid.
Förväntar sig investerare en MVP?
Många tidiga investerare nöjer sig med en stark prototyp, belägg från kunder och en trovärdig plan. En del svensk offentlig finansiering täcker också stegen före en MVP. Fråga vilka belägg de behöver innan du väljer vad du bygger.
Vad händer om jag hoppar direkt till en MVP?
Det kan fungera när idén är väl förstådd och tekniken beprövad. Risken är att större delen av budgeten går till funktioner ingen använder, eftersom ingen testade idén först.
Osäker på vilket steg som kommer härnäst?
Beskriv idén och ditt största tvivel i ett kort samtal. Vi säger om en prototyp, en proof of concept eller en MVP är det som besvarar det.
Boka ett kostnadsfritt 15-minuterssamtal