PoC eller MVP?
Et proof of concept, PoC, beviser at noget kan bygges teknisk: Kan API’et klare belastningen, virker algoritmen, holder integrationen? En MVP beviser at nogen faktisk vil bruge og betale for produktet. PoC’en svarer på om det kan bygges, MVP’en på om det bør bygges. Hvilken du har brug for først, afhænger af hvor den største risiko ligger.
PoC og MVP lyder som den samme slags tidlige eksperiment, men de besvarer vidt forskellige spørgsmål. Et proof of concept beviser at noget kan bygges teknisk. Et minimum viable product beviser at nogen vil bruge og betale for det. Det ene tager brodden af den tekniske risiko, det andet af markedsrisikoen, og at vide hvilken af dem du står over for, afgør hvor du skal begynde. Spørgsmålet er særlig almindeligt i AI- og integrationsprojekter, hvor teknikken oftere er et åbent spørgsmål.
Kan det bygges, eller vil nogen bruge det?
En PoC stiller spørgsmålet kan det her overhovedet bygges? Kan API’et klare belastningen? Når AI-modellen en tilstrækkelig træfsikkerhed? Kan det integreres med det gamle ERP-system? En PoC er derfor ofte smal og teknisk, bygget til at besvare ét enkelt spørgsmål af den slags, og den mangler som regel en færdig brugerflade fordi den ikke er til brugere, men skal bevise noget over for teamet.
En MVP stiller i stedet spørgsmålet vil nogen faktisk bruge det her? Den er et rigtigt, nedskaleret produkt der møder rigtige brugere i drift, og det den måler, er adfærd: Kommer folk tilbage, gennemfører de flowet, betaler de?
Kort sagt: PoC’en adresserer teknisk risiko, MVP’en markedsrisiko. Bruger du det forkerte værktøj, får du med sikkerhed svar på det forkerte spørgsmål.
Typiske forløb: Hvor ligger risikoen?
Hvilken rækkefølge der er den rigtige, afgøres af hvor den største usikkerhed ligger.
- Projekter med teknisk risiko: PoC først, derefter MVP. Når det store spørgsmål er om løsningen overhovedet kan bygges, f.eks. ved en ny algoritme, en uafprøvet integration eller et hårdt krav til ydeevnen, så start med en PoC. Falder den, har du sparet en hel produktinvestering. Holder den, så byg MVP’en på indsigten og test forretningen.
- Projekter med markedsrisiko: direkte til MVP. Når teknikken er velafprøvet, men det er usikkert om nogen vil have produktet, er en PoC spildt tid. Gå direkte til en MVP, og brug kræfterne på at teste efterspørgslen.
- Begge dele: PoC på den kritiske tekniske del, derefter en MVP omkring den. Nogle gange er der både et teknisk nøglespørgsmål og et markedsspørgsmål. Så afgrænses PoC’en til netop den usikre teknik, og når den er løst, bygges den MVP der tester helheden.
De fleste projekter lander i et af disse forløb. At sætte ord på hvilken risiko der vejer tungest, er ofte den mest værdifulde beslutning i hele opstarten.
Den typiske fejl: PoC’en der i det stille ender i produktion
Her snubler mange. En PoC bliver bygget hurtigt for at bevise en pointe, den virker, og nogen siger: “Den virker jo allerede, kan vi ikke bare bygge videre på den?” Så glider provisoriet umærkeligt ind i produktion.
Problemet er at en PoC bevidst springer over det der gør et produkt holdbart: fejlhåndtering, sikkerhed, tests og struktur. Den blev bygget til at besvare et spørgsmål, ikke til at leve i drift. Når den alligevel bliver sat i produktion, bygges der teknisk gæld ind i selve fundamentet, og regningen kommer senere i form af fejl, sikkerhedshuller og en kodebase der er svær at bygge videre på.
Modmidlet er en beslutning på forhånd: PoC’en skal smides ud. Det er læringen der føres videre, ikke koden. MVP’en bygges derefter på det rigtige fundament, med viden om at teknikken holder.
Et konkret scenarie
En virksomhed ville bygge en tjeneste der automatisk fortolker indscannede fakturaer med AI. Den store usikkerhed var teknisk: Bliver træfsikkerheden god nok til at være brugbar? De byggede en PoC på et par uger, kørte den på hundredvis af rigtige fakturaer og konstaterede at den nåede et brugbart niveau, med tydelige undtagelser for håndskrevne felter.
I stedet for at sætte PoC’en i drift brugte de den som beslutningsgrundlag og smed den derefter ud. MVP’en blev så bygget for alvor, med fejlhåndtering og et flow til de tilfælde hvor AI’en var usikker og et menneske skulle tage over. PoC’en besvarede kan det bygges, og MVP’en gik videre til vil nogen bruge det: i den rigtige rækkefølge og uden at provisoriet blev fundamentet for produktet.
Sådan vælger du det rigtige startpunkt
Spørg hvilken risiko der ville vælte satsningen: at det ikke kan bygges, eller at ingen vil have det? Ligger den tunge usikkerhed i teknikken, så start med en PoC. Ligger den i markedet, så gå direkte til en MVP. Hos Weapp afklarer vi ofte netop det spørgsmål først i AI- og integrationsprojekter, som en del af vores ydelser.
Usikker på hvor din største risiko ligger? Kontakt os, så hjælper vi dig med at placere den og vælge det rigtige første skridt.
Ofte stillede spørgsmål
Hvad er den vigtigste forskel på en PoC og en MVP?
Hvilket spørgsmål de besvarer. En PoC besvarer om det her kan bygges, et teknisk spørgsmål, ofte uden brugerflade. En MVP besvarer om nogen vil bruge det, et forretningsspørgsmål der kræver rigtige brugere. Den ene adresserer teknisk risiko, den anden markedsrisiko. Blander man dem sammen, tester man det forkerte.
Har alle projekter brug for en PoC?
Nej. En PoC er først berettiget når der er en reel teknisk usikkerhed: en ny algoritme, en tvivlsom integration, et krav til ydeevnen som ingen ved om kan opfyldes. Bygger du noget teknisk velafprøvet, er PoC’en spildt tid; gå direkte til en MVP. PoC’en hører hjemme dér hvor svaret på om det kan bygges, ikke er et selvfølgeligt ja.
Kan en PoC videreudvikles til en MVP?
Sjældent direkte, og det er en almindelig fælde. En PoC bliver bygget for at bevise en pointe hurtigt og mangler ofte fejlhåndtering, sikkerhed og den struktur der skal til for at holde i drift. At bygge videre på den betyder at man stabler produktion oven på et provisorium. Som regel er det klogere at tage læringen fra PoC’en og bygge MVP’en på det rigtige fundament.
Hvorfor nævnes PoC oftere i AI- og integrationsprojekter?
Fordi den tekniske risiko er mærkbar dér. Om en AI-model kan nå en tilstrækkelig træfsikkerhed, eller om en integration med et gammelt system overhovedet er mulig, er åbne spørgsmål som det er billigere at besvare med en PoC før man bygger et helt produkt. I projekter med velkendt teknologi er en tilsvarende usikkerhed sjælden.
Hvad er risikoen ved at lade en PoC blive til produktion?
At der bygges teknisk gæld ind i fundamentet fra start. En PoC der i det stille bliver sat i drift, mangler det der gør et produkt holdbart, altså fejlhåndtering, sikkerhed og tests, og problemerne dukker op senere når de er dyrere at udbedre. Beslut på forhånd at PoC’en skal smides ud så læringen føres videre, men ikke koden.