Du sitter i ett möte. Din chef frågar: "Kan vi bygga en POC för att testa den här idén?"

Ditt utvecklingsteam nickar och börjar planera en MVP. Leverantören återkommer med en offert på en prototyp. Och plötsligt talar alla om olika saker.

Här är problemet: POC, prototyp och MVP används ofta som utbytbara begrepp — men de är fundamentalt olika leveranser med olika syfte, tidsåtgång och kostnad.

Att blanda ihop dem kostar tid och pengar. Ber du om en POC när du behöver en MVP? Då får du något som bevisar att det går att bygga, men som inte kan lanseras mot användare. Bygger du en MVP när en prototyp hade räckt? Då har du precis lagt ut ungefär tre gånger så mycket som nödvändigt.

Låt oss reda ut det en gång för alla.

POC: proof of concept (konceptbevis)

Syfte: Besvara en specifik teknisk fråga. Går det här överhuvudtaget att göra?

En POC bevisar teknisk genomförbarhet. Det är det minsta möjliga experimentet för att validera att en viss ansats eller teknik fungerar.

Så ser en POC ut

  • Tidsåtgång: 1–2 veckor
  • Relativ investering: Lägsta nivån — riktmärke 1× (referenspunkten för de andra två)
  • Målgrupp: Internt tekniskt team
  • Detaljnivå: Absolut minimum — ofta bara backendkod, inget gränssnitt
  • Kodkvalitet: Slit-och-släng (inte produktionsfärdig)

När du behöver en POC

  • Testa integration mot ett äldre system ("Kan vi hämta ut data ur det här affärssystemet från 90-talet?")
  • Validera en ny teknik ("Klarar den här modellen att klassificera våra data tillräckligt träffsäkert?")
  • Bevisa prestanda vid skala ("Klarar den här arkitekturen 10 000 samtidiga användare?")
  • Minska risk före en större investering ("Är realtidsbearbetning av video tekniskt genomförbart?")

Exempel: Ert team vill bygga en tjänst som använder AI för att analysera inspelade kundsamtal. Innan ni binder upp en hel MVP-budget bygger ni en POC: ett enkelt skript som bearbetar 100 exempelsamtal och mäter träffsäkerheten. Tidsåtgång: tio dagar. Resultat: ni vet nu om kärntekniken håller innan ni förbinder er till full utveckling. Ett extra svenskt förbehåll: om samtalen innehåller personuppgifter behöver även POC:en en rättslig grund och ett biträdesavtal — det är inte något man skjuter till MVP-fasen.

Prototyp: användarupplevelse och flöden

Syfte: Visa hur det kommer att se ut och kännas. Validera användarupplevelsen.

En prototyp demonstrerar användarresan och gränssnittsdesignen. Den ser äkta ut, men fungerar inte nödvändigtvis under ytan.

Så ser en prototyp ut

  • Tidsåtgång: 2–4 veckor
  • Relativ investering: Ungefär 2–3× en POC
  • Målgrupp: Intressenter, ledning, potentiella användare
  • Detaljnivå: Hög visuell trovärdighet, begränsad funktionalitet
  • Kodkvalitet: Demoklar (fungerar för presentationer, inte för produktion)

När du behöver en prototyp

  • Förankra beslutet hos intressenter
  • Testa användarupplevelsen med riktiga användare före full utveckling
  • Demonstrera visionen för investerare eller ledningsgrupp
  • Skapa samsyn om användarupplevelsen mellan avdelningar
  • Få budget godkänd för ett större projekt

Exempel: Ert produktteam har en idé om en intern dashboard som kopplar ihop fem affärssystem. Innan budget för fullt bygge godkänns bygger ni en prototyp på tre veckor med realistiskt gränssnitt, exempeldata och klickbara flöden. Intressenterna kan "använda" den i en demo, se värdet och godkänna produktionsbudgeten. Investeringen ligger i storleksordningen några procent av det fulla byggets budget — en billig försäkring mot att bygga fel sak.

MVP: minimum viable product

Syfte: Lansera mot riktiga användare och börja lära av marknaden.

En MVP är den minsta versionen av produkten som levererar verkligt värde till verkliga användare. Den är produktionsfärdig, skalbar och byggd för att gå live.

Så ser en MVP ut

  • Tidsåtgång: 4–8 veckor
  • Relativ investering: Ungefär 6–8× en POC
  • Målgrupp: Riktiga användare på marknaden
  • Detaljnivå: Fullt funktionell, produktionsfärdig
  • Kodkvalitet: Produktionsklass (säker, testad, förvaltningsbar)

När du behöver en MVP

  • Testa produkt-marknadspassning med riktiga användare
  • Lansera innan kapitalet tar slut
  • Generera intäkter eller dragkraft inför en finansieringsrunda
  • Ersätta manuella arbetsflöden med en fungerande lösning
  • Starta kundanskaffning och återkopplingsloopar

Exempel: Ni är ett startup med tre månaders kapital kvar. Ni behöver en fungerande SaaS-produkt för att börja skaffa kunder och visa dragkraft för investerare. Ni bygger en MVP på sex veckor med kärnfunktionerna: inloggning, betalhantering, ert huvudsakliga arbetsflöde och enkel administration. Användare kan registrera sig, betala och få värde. Resultat: en levande produkt med riktiga betalande kunder.

POC, prototyp och MVP: jämförelse sida vid sida

Dimension POC Prototyp MVP
Primärt syfte Bevisa teknisk genomförbarhet Validera användarupplevelsen Lansera på marknaden
Nyckelfråga "Kan vi bygga det här?" "Bör vi bygga det här?" "Vill användare betala för det?"
Målgrupp Internt tekniskt team Intressenter, ledning, testanvändare Riktiga användare på marknaden
Tidsåtgång 1–2 veckor 2–4 veckor 4–8 veckor
Relativ investering 1× (riktmärke) 2–3× 6–8×
Visuell detaljnivå Ingen (endast backend) Hög (ser äkta ut) Produktionsfärdig
Funktionalitet Endast kärnteknik Demoflöden (ingen riktig backend) Fullt funktionell
Kodkvalitet Slit-och-släng Demoklar Produktionsklass
När den passar Hög teknisk osäkerhet Behov av förankring Redo att lansera och lära

Observera att kolumnen "relativ investering" medvetet uttrycks som förhållanden, inte som belopp. Faktiska priser varierar kraftigt beroende på leverantör, domänkomplexitet och hur mycket av kravarbetet ni gör själva — men förhållandet mellan de tre leveranstyperna är påfallande stabilt.

Beslutsramverk: vad ska du bygga?

Osäker på vilken ansats som passar? Använd det här beslutsträdet:

Börja här: har du en specifik teknisk risk?

JA → Är tekniken obeprövad eller osäker?
JA → Bygg en POC
NEJ → Fortsätt nedan

NEJ → Behöver du förankra beslutet eller få budget godkänd?
JA → Behöver intressenterna "se det" för att godkänna?
JA → Bygg en prototyp
NEJ → Fortsätt nedan

NEJ → Är ni redo att lansera mot riktiga användare?
JA → Bygg en MVP

Fortfarande osäker?

  • Om du främst besvarar "kan vi?" → POC
  • Om du främst besvarar "bör vi?" → prototyp
  • Om du främst besvarar "vill de betala?" → MVP

Vanliga misstag (och hur du undviker dem)

Misstag 1: Bygga en MVP när du behöver en prototyp

Ni vill testa en idé med intressenter och få budget godkänd. I stället för en prototyp beställer ni en fullständig MVP med backend, databas och produktionsinfrastruktur.

Problemet: Ni har lagt ungefär tre gånger så mycket som nödvändigt på något som bara kommer att användas i interna demos.

Bättre ansats: Bygg en prototyp med hög visuell trovärdighet först. Blir den godkänd — investera då i produktions-MVP:n.

Misstag 2: Hoppa över POC:en när den tekniska risken är hög

Ni är till 60 % säkra på att integrationen mot ett äldre system kommer att fungera. Ni hoppar över POC:en och går direkt på MVP-bygget. Fyra veckor in upptäcker ni att det gamla systemet inte stödjer de anrop ni behöver.

Problemet: Nu sitter ni med en betydande investering i ett projekt som är fundamentalt blockerat.

Bättre ansats: Lägg ett par veckor på en POC för att avriska de tekniska okända innan ni binder er till full utveckling. Kostnaden för POC:en är en bråkdel av vad fyra bortkastade utvecklingsveckor är.

Misstag 3: Behandla en prototyp som en MVP

Ni bygger en vacker prototyp, demar den för ledningen och de älskar den. De säger: "Toppen, vi lanserar nästa vecka!" Men prototypen var aldrig byggd för produktion — den har ingen säkerhet, ingen felhantering, och den går sönder under verklig last.

Problemet: Ni har satt förväntningen att produkten är klar när den i själva verket har en betydande del kvar till lanseringsfärdig.

Bättre ansats: Var uttrycklig med vad ni bygger. Är det en prototyp — säg till intressenterna att det är en demoversion och beskriv vad som krävs för att göra den produktionsfärdig.

Vägen framåt: hur de sekvenseras

I många fall bygger ni mer än en. Så här hänger de ihop:

Väg 1: Hög teknisk risk
POC (2 veckor) → prototyp (3 veckor) → MVP (6 veckor)

Väg 2: Behöver förankring först
Prototyp (3 veckor) → MVP (6 veckor)

Väg 3: Redo att lansera
MVP (6 veckor) → iterera utifrån användarfeedback

Slutsats: enas om definitionerna innan ni börjar

Det största misstaget är inte att välja fel leverans. Det är att anta att alla använder samma definition.

Innan ni drar igång något projekt, enas med era intressenter om:

  • Vad är det vi faktiskt bygger?
  • Vem är målgruppen?
  • Hur ser "klart" ut?
  • Vad är syftet — validering, godkännande eller lansering?

Får ni det rätt sparar ni tid, pengar och en hel del frustration.