PoC eller MVP?
En proof of concept, PoC, bevisar att något går att bygga tekniskt – klarar API:et lasten, fungerar algoritmen, håller integrationen? En MVP bevisar att någon faktiskt vill använda och betala för produkten. PoC:n svarar på om det kan byggas, MVP:n på om det bör byggas. Vilken du behöver först styrs av var den största risken sitter.
PoC och MVP låter som samma sorts tidiga experiment, men de svarar på helt olika frågor. En proof of concept bevisar att något går att bygga tekniskt. En minimum viable product bevisar att någon vill använda och betala för det. Den ena tar udden av teknikrisk, den andra av marknadsrisk – och att veta vilken du står inför avgör var du ska börja. Frågan är särskilt vanlig i AI- och integrationsprojekt, där tekniken oftare är en öppen fråga.
Kan det byggas kontra vill någon använda det
En PoC ställer frågan kan det här över huvud taget byggas? Klarar API:et lasten? Når AI-modellen tillräcklig träffsäkerhet? Går det att integrera mot det gamla affärssystemet? En PoC är därför ofta smal och teknisk, byggd för att svara på en enda sådan fråga – och den saknar vanligen ett färdigt gränssnitt, eftersom den inte är till för användare utan för att bevisa något inför teamet.
En MVP ställer i stället frågan vill någon faktiskt använda det här? Den är en riktig, avskalad produkt som möter verkliga användare i drift, och det den mäter är beteende: kommer folk tillbaka, slutför de flödet, betalar de?
Kärnan: PoC:n adresserar teknikrisk, MVP:n marknadsrisk. Använder du fel verktyg svarar du säkert på fel fråga.
Typiska sekvenser: var sitter risken?
Vilken ordning som är rätt avgörs av var den största osäkerheten ligger.
- Teknikrisk-projekt: PoC först, sedan MVP. När den stora frågan är om lösningen alls är möjlig att bygga – en ny algoritm, en oprövad integration, ett hårt prestandakrav – börja med en PoC. Faller den har du sparat en hel produktinvestering. Håller den, bygg MVP:n på insikten och testa affären.
- Marknadsrisk-projekt: direkt MVP. När tekniken är välbeprövad men det är osäkert om någon vill ha produkten, är en PoC bortkastad tid. Gå direkt på en MVP och lägg krutet på att testa efterfrågan.
- Bådadera: PoC på den kritiska tekniska biten, sedan MVP runt den. Ibland finns både en teknisk knäckfråga och en marknadsfråga. Då avgränsas PoC:n till just den osäkra tekniken, och när den är löst byggs MVP:n som testar helheten.
De flesta projekt landar i en av dessa. Att sätta ord på vilken risk som väger tyngst är ofta det mest värdefulla beslutet i hela starten.
Det vanliga misstaget: PoC:n som smygblir produktion
Här snubblar många. En PoC byggs snabbt för att bevisa en punkt, den fungerar, och någon säger: “den funkar ju redan – kan vi inte bara bygga vidare på den?” Så glider provisoriet omärkligt in i produktion.
Problemet är att en PoC medvetet hoppar över det som gör en produkt hållbar: felhantering, säkerhet, tester, struktur. Den var byggd för att svara på en fråga, inte för att leva i drift. När den ändå sätts i produktion byggs teknisk skuld in i själva fundamentet, och notan kommer senare – i form av buggar, säkerhetshål och en kodbas som är svår att bygga vidare på.
Motmedlet är ett beslut på förhand: PoC:n ska slängas. Det är lärdomen som tas vidare, inte koden. MVP:n byggs sedan på rätt grund, med kunskapen om att tekniken bär.
Ett konkret scenario
Ett bolag ville bygga en tjänst som automatiskt tolkar inskannade fakturor med AI. Den stora osäkerheten var teknisk: blir träffsäkerheten god nog för att vara användbar? De byggde en PoC på ett par veckor, körde den mot hundratals verkliga fakturor och konstaterade att den nådde en användbar nivå – med tydliga undantag för handskrivna fält.
I stället för att sätta PoC:n i drift användes den som beslutsunderlag och slängdes. MVP:n byggdes därefter på riktigt, med felhantering och ett flöde för de fall där AI:n var osäker och en människa fick ta över. PoC:n besvarade kan det byggas; MVP:n gick vidare till vill någon använda det – i rätt ordning, och utan att provisoriet blev grund för produkten.
Så väljer du rätt startpunkt
Fråga vilken risk som skulle sänka satsningen: att det inte går att bygga, eller att ingen vill ha det? Ligger den tunga osäkerheten i tekniken, börja med en PoC. Ligger den i marknaden, gå direkt på en MVP. Vi på Weapp reder ofta ut just den frågan först i AI- och integrationsprojekt, som en del av våra tjänster.
Osäker på var din tyngsta risk sitter? Hör av dig så hjälper vi dig placera den – och välja rätt första steg.
Vanliga frågor
Vad är den viktigaste skillnaden mellan PoC och MVP?
Vilken fråga de svarar på. En PoC svarar på kan det här byggas – en teknisk fråga, ofta utan användargränssnitt. En MVP svarar på vill någon använda det – en affärsfråga som kräver riktiga användare. Den ena adresserar teknikrisk, den andra marknadsrisk. Blandar man ihop dem testar man fel sak.
Behöver alla projekt en PoC?
Nej. En PoC är motiverad först när det finns en verklig teknisk osäkerhet – en ny algoritm, en tvivelaktig integration, ett prestandakrav ingen vet om det håller. Bygger du något tekniskt välbeprövat är PoC:n bortkastad tid; gå direkt på MVP. PoC:n hör hemma där svaret på kan det byggas inte är självklart ja.
Kan en PoC utvecklas vidare till en MVP?
Sällan direkt, och det är en vanlig fälla. En PoC byggs för att snabbt bevisa en punkt och saknar ofta felhantering, säkerhet och struktur för att hålla i drift. Att bygga vidare på den betyder att skjuta produktion ovanpå ett provisorium. Oftast är det klokare att ta lärdomen från PoC:n och bygga MVP:n på rätt grund.
Varför nämns PoC oftare i AI- och integrationsprojekt?
För att teknikrisken är påtaglig där. Om en AI-modell ska nå tillräcklig träffsäkerhet, eller om en integration mot ett gammalt system alls är möjlig, är öppna frågor det är billigare att svara på med en PoC innan man bygger en hel produkt. I projekt med välkänd teknik är motsvarande osäkerhet ovanlig.
Vad är risken med att låta en PoC bli produktion?
Att teknisk skuld byggs in i grunden från start. En PoC som smygsätts i drift saknar det som gör en produkt hållbar – felhantering, säkerhet, tester – och problemen dyker upp senare, när de är dyrare att åtgärda. Bestäm på förhand att PoC:n ska slängas, så att lärdomen tas vidare men inte koden.