MVP-utvikling i Oslo
En MVP er den minste versjonen av et produkt som viser om ideen holder hos ekte brukere før hele budsjettet er brukt. Vi starter med en workshop som skjærer bort alt utenom kjernehypotesen, bygger med teknologi som kan videreutvikles, og måler bruken fra første dag. For team i Oslo holder vi gjerne workshopen hos dere.
De fleste nye digitale produkter starter med en lang ønskeliste. Det som avgjør om de lykkes, er sjelden listen, men om noen faktisk vil bruke kjernen i produktet. En MVP, et minimum viable product, er den minste versjonen som gir et ærlig svar på det spørsmålet. Hos Weapp hjelper vi team med å finne det svaret. Vi er rundt 38 utviklere, designere og strateger i et digitalt produktbyrå i Göteborg, og vi møter gjerne gründere og produktteam i Oslo.
Oslo: mange ideer som skal testes
Oslo har et aktivt miljø for nye selskaper. StartupLab i Gaustadalléen 21 skriver at de huser over 100 aktive startups samtidig, at de har jobbet med mer enn 550, og at de har investert i over 185 selskaper. Ifølge Oslo Innovation Week, som drives av Oslo&Co og eies og støttes av Oslo kommune, kom 15 000 deltakere fra 40 land til innovasjonsuken i 2025, og 404 risikokapitalister deltok.
En ny idé bør testes raskt og på ekte brukere før det bygges stort. Det er akkurat det en MVP er til for. Skal selskapet hente kapital, kan tall på faktisk bruk dessuten si mer enn en presentasjon alene.
Prioriteringsworkshopen: Hva må bevises først?
Den tekniske delen av en MVP er sjelden den tyngste. Det som krever mest, er å bestemme hva som ikke skal være med. Nesten hver idé bærer på en lang rekke funksjoner som føles nødvendige, men bare noen få avgjør om forretningen holder.
Derfor starter vi med en workshop der vi sammen ringer inn kjernehypotesen: Hva må være sant for at dette skal bli en forretning? Rundt den bygges MVP-en, og alt annet legges bevisst til side, ikke for alltid, men til hovedspørsmålet er besvart.
Workshopen krever ingen ferdig kravspesifikasjon, for en tydelig idé er nok til å begynne. Den holder vi gjerne hos dere i Oslo. Det er lettere å gi slipp på en funksjon man er glad i når man sammen ser at den ikke trengs for å bevise noe.
Teknologivalg som tåler neste steg
En MVP skal bygges raskt, men ikke på hvilken som helst måte. Noen snarveier sparer uker nå og koster måneder senere fordi de låser produktet til en løsning som ikke kan bære videre. Vi velger derfor teknologi med to spørsmål i bakhodet: Kan den bære en videreutvikling hvis hypotesen holder? Og kan den bære et retningsskifte hvis brukerne viser noe uventet?
Noen ganger er et rent engangseksperiment likevel det smarteste, bygget for å kastes når det har gitt svaret sitt. Det avgjør vi sammen med dere, bevisst og ikke av vane. Forskjellen på de to veiene har vi beskrevet i MVP vs. prototype. Om en enklere POC er nok, har vi skrevet om i POC vs. MVP.
Sejfa: en ny digital tjeneste fra bunnen
Å bygge en helt ny digital tjeneste er nettopp den typen oppgave en MVP er laget for. Et eksempel fra vår egen portefølje er Sejfa, en digital innboforsikring for unge voksne.
Å lansere en ny forsikringstjeneste for en målgruppe som tradisjonelt er vanskelig å nå, krever raske svar på om konseptet treffer: Forstår brukerne tilbudet, stoler de på det, og vil de tegne forsikringen? Slike spørsmål besvares best av en tjeneste som fungerer, i hendene på ekte brukere, ikke av flere antakelser i et dokument. Sejfa viser hvordan et nytt digitalt produkt kan gå fra idé til noe folk faktisk bruker.
Scenario: et gründerteam i Oslo
Et gründerteam i Oslo har en idé til en tjeneste, en lang funksjonsliste og en plan om å hente kapital om et halvt år. På workshopen skalerer vi listen ned til det ene spørsmålet som avgjør alt: Kommer brukerne tilbake og betaler for kjerneverdien?
MVP-en bygges rundt akkurat det og lanseres i løpet av noen måneder, med måling bygget inn fra start. Tallene viser at mange faller fra på et uventet sted, et problem som aldri ville ha dukket opp i en kravliste. Det rettes i neste iterasjon, og først etterpå bygges funksjonene teamet opprinnelig trodde var viktigst. Når teamet møter investorer, kan det vise faktisk bruk i stedet for bare en visjon.
Etter lansering: måle, lære, iterere
En utbredt misforståelse er at jobben er gjort når MVP-en er lansert. Egentlig er det da det viktigste begynner.
- Måle. Vi måler hvordan tjenesten faktisk brukes: hvor brukerne kommer inn, hvor de stopper opp, og hvor de faller fra.
- Lære. Tallene og atferden viser hva som fungerer og hva som ikke gjør det, ofte på uventede måter.
- Iterere. Ut fra det dere ser, prioriteres neste steg. Kanskje skal en funksjon bygges ut, kanskje fjernes, kanskje peker alt mot noe dere ikke hadde forutsett.
Den sløyfen er hele poenget med å bygge en MVP i stedet for å gjette seg frem til et ferdig produkt. Forskjellen mellom de to har vi utdypet i MVP vs. ferdig produkt.
Møter i Oslo, utvikling i Göteborg
Koden skrives av teamet i Göteborg. Dere følger arbeidet på faste statusmøter over video og kan prøve testversjoner underveis. De avgjørende prioriteringene tjener likevel på å bli tatt i samme rom, så workshoper, demoer og viktige beslutninger tar vi gjerne hos dere i Oslo. Togreisen fra Göteborg er på rundt tre og en halv time, ifølge Vy.
Neste steg
Hva en MVP koster, avhenger mest av hvor skarpt kjernehypotesen er avgrenset. Guiden hva koster en MVP viser prisnivåene, og tjenestene våre viser hva vi ellers bygger. Har dere en idé som fortjener en ekte test? Ta kontakt, så finner vi sammen hypotesen som er verdt å bevise først.
Ofte stilte spørsmål
Hvor lang tid tar det å bygge en MVP?
Ofte noen få måneder, men det avhenger av hvor skarpt kjernehypotesen er avgrenset. Det som styrer tiden, er omfanget, ikke hvor raskt teamet jobber. Jo smalere omfang, desto raskere lansering, og derfor bruker vi tid i starten på å skjære bort alt som ikke trengs for å bevise forretningsideen.
Må vi ha en ferdig kravspesifikasjon før vi tar kontakt?
Nei. En tydelig idé og en formening om hvem den er for, er nok. Hva MVP-en skal bevise, og hva som kan vente, finner vi ut sammen i prioriteringsworkshopen. Har dere skisser eller notater fra samtaler med mulige kunder, er det nyttig å ta dem med, men det er ikke et krav. Møtet kan gjerne være hos dere i Oslo.
Hva er forskjellen på en MVP og en prototype?
En prototype er en modell som viser hvordan noe skal se ut og fungere, ofte klikkbar, men uten ekte funksjonalitet bak. En MVP er et fungerende produkt, avgrenset til kjernen, som ekte brukere kan ta i bruk. Prototypen tester om en løsning er forståelig. MVP-en tester om noen faktisk vil bruke den og betale for den.
Hvordan hjelper en MVP i samtaler med investorer?
Den erstatter antakelser med bevis. En MVP med ekte brukere viser at noen vil ha produktet, og hvordan de bruker det. Vi bygger derfor inn måling av bruk, aktivering og tilbakevendende bruk fra første dag slik at dere har faktiske tall å vise frem når det er tid for å hente kapital.
Bygger dere MVP-er som kan skaleres videre?
Ja, når det er riktig vei. Vanligvis velger vi teknologi og arkitektur som kan bære videre slik at en MVP som har vist seg å holde, kan vokse til det ferdige produktet i stedet for å skrives om. Noen ganger er et rent engangseksperiment smartere, og det valget tar vi bevisst sammen med dere fra start.