Hva er en MVP, og hvordan lager man en?

Begrepet blir vanligvis tilskrevet Frank Robinson i selskapet SyncDev, som brukte det i 2001, ifølge Wikipedia. Det ble kjent i oppstartsmiljøer gjennom Steve Blank og Eric Ries, og særlig gjennom Ries' bok The Lean Startup fra 2011.

Ries beskriver en MVP som den versjonen av et nytt produkt som lar teamet lære mest mulig om kundene med minst mulig innsats (Startup Lessons Learned, 2009). Definisjonen handler om læring. Den sier ingenting om hvor mange funksjoner produktet skal ha eller hvor billig det skal være å lage.

Et nytt digitalt produkt bygger på antakelser, som at folk har problemet dere tror de har, og at noen av dem vil betale for å få det løst. En MVP tester den viktigste antakelsen med ekte brukere, så dere slipper å bruke hele budsjettet før dere vet om ideen holder.

Svaret kommer fra det folk gjør. At noen sier i et intervju at de ville brukt appen, betyr lite sammenlignet med at de laster den ned, åpner den igjen uka etter og legger inn kortnummeret. Derfor må en MVP være god nok til at folk kan bruke den på ordentlig.

Vi begynte på Unveil, et delt engangskamera for bryllup og fester, i juli 2026. I september hadde appen betalende kunder i 12 land. Slike betalinger er et sterkere signal enn noe intervju kan gi.

Start med én jobb produktet skal gjøre for brukeren. Tenk dere en bookingapp for en fysioterapiklinikk. Jobben er at en pasient finner en ledig time og bestiller den. Lojalitetsprogram, chat med terapeuten og flere språk kan vente til dere ser at folk bestiller.

Velg så én type bruker å lage den første versjonen for. Bookingappen har både pasienter og ansatte, og begge grupper har ønsker. I starten kan de ansatte ofte klare seg med et enkelt adminpanel, mens pasientene får en app som fungerer godt.

Bestem til slutt hvilket tall som skal vise om det fungerer, før dere begynner å bygge. Det kan være andelen som fullfører en bestilling, eller hvor mange som går fra prøveperiode til abonnement. Med tallet bestemt på forhånd blir det lettere å si nei til funksjoner som ikke påvirker det.

Den vanligste feilen er å ta med for mye i første versjon. Hver funksjon skal designes, bygges, testes og vedlikeholdes. Med mange funksjoner blir det også vanskeligere å se hva som fikk folk til å bli, og hva som fikk dem til å slutte.

En annen feil er å lansere uten måling. Da står dere igjen med inntrykk og enkeltmeldinger fra brukere, og de er lette å tolke slik man selv ønsker.

Det går også an å gå for langt i den andre retningen. En MVP som krasjer eller er vanskelig å forstå, sier lite om ideen, fordi folk slutter på grunn av utførelsen. Første versjon kan ha få funksjoner, men de som er med, må fungere.

Det er også lett å begynne å bygge før dere har snakket med noen i målgruppen. Noen få samtaler kan vise at problemet ser annerledes ut enn dere trodde, og det er mye billigere å oppdage før koden er skrevet.

Noen spørsmål kan besvares billigere enn med et ferdig produkt. Disse metodene passer i hver sin situasjon:

• Klikkbar prototype: skisser som ser ut og oppfører seg som en app. Passer når dere vil se om folk forstår løsningen og finner fram, eller skal vise ideen til investorer.
• Landingsside: en nettside som beskriver produktet og ber folk skrive seg på en venteliste eller forhåndsbestille. Passer når spørsmålet er om nok folk er interessert.
• Manuell tjeneste: kunden får resultatet, men dere gjør jobben for hånd bak kulissene. Passer når dere vil teste om folk betaler for resultatet før dere automatiserer det.

Hos oss starter første versjon av en app, en webapp eller et system på 150 000 kr eks. mva., og den havner som regel mellom 150 000 og 500 000 kr. Prisen avhenger mest av hvor mange skjermer og funksjoner det er, og om brukerne skal betale i løsningen. Mer om hva som trekker prisen opp og ned, står på prissiden.

En første versjon tar som regel to til fire måneder. Når vi lager en app, tester vi skisser på folk som skal bruke den før vi skriver koden, fordi en skisse er billig å endre. Har dere en idé dere vil ha et anslag på, kan dere sende oss en beskrivelse, så svarer vi med hva vi mener første versjon bør inneholde.

Sett opp måling før lansering. Et verktøy som PostHog viser hvor brukerne stopper underveis, hvilke funksjoner de bruker og hvor mange som kommer tilbake. Vi bruker PostHog i våre egne apper og setter det opp i nye produkter også.

Tar produktet betalt, er andelen som går fra gratisbruk eller prøveperiode til betalende det viktigste tallet. QuitNic, appen vår for å slutte med røyk, snus og e-sigaretter, kom ut i juni 2025 og har blitt oppdatert jevnlig siden. Betalingsskjermene styres fra Superwall, så vi kan teste nye varianter uten å sende en ny versjon til App Store.

Etter noen uker med tall bør dere kunne avgjøre om dere skal bygge videre på det dere har, endre retning eller legge ideen bort.