Guide · MVP och SaaS
Vad kostar en MVP? Det här avgör priset
Av din Pohlare · 6 min läsning
Vad en MVP är, och vad den inte är
En MVP, minsta fungerande produkt, är den minsta version av en produkt som en riktig kund är beredd att betala för. Den ska svara på en enda fråga: vill kunderna ha det här tillräckligt mycket för att betala?
Det är inte en demo eller en klickbar prototyp. En demo visar hur något kan se ut. En MVP klarar mötet med verkligheten: registrering, betalning, det första supportmejlet och en användare som gör något oväntat. Därför går det inte att hoppa över grunderna, hur litet resten än är.
De sex sakerna som styr priset
- Antal användarflöden. Varje sak en användare ska kunna göra från början till slut, som att skapa ett konto, skicka en offert eller boka en tid, är ett flöde. Fem tydliga flöden är en helt annan sak än femton.
- Inloggning, konton och roller. En app där alla ser samma sak är enkel. Så fort det finns företag, team och behörigheter växer arbetet.
- Betalning och abonnemang. Att ta betalt en gång är enklare än abonnemang med provperiod, uppgradering, kvitton och misslyckade betalningar.
- Integrationer. Allt som ska prata med andra system, som BankID, mejl och sms, bokföring eller ert CRM, tar tid. Varje system har sina egna regler och sin egen dokumentation.
- Designens nivå. En ren och enkel design går snabbt. Egna animationer, många skärmstorlekar och ett detaljerat designsystem lägger på tid.
- AI-funktioner. En assistent som ska skriva, sammanfatta eller svara kräver både bygg- och driftsarbete, och en löpande kostnad för modellanvändningen.
Fast pris eller timpris
Det som är tydligt avgränsat går att offerera till fast pris. Då vet ni kostnaden innan vi börjar, och risken för att arbetet drar iväg ligger hos den som bygger.
Efter lansering ändras bilden. Ni lär er vad användarna faktiskt gör, och listan över nästa funktioner ändras varje vecka. Då passar det bättre att offerera varje ny funktion för sig, eller att ta betalt efter tid.
Så får du en offert du kan jämföra
Skriv ner några rader innan du ber om offert, så blir offerterna jämförbara:
- Vem är produkten för, och vilket problem löser den?
- De tre viktigaste sakerna en användare ska kunna göra.
- Hur ska ni ta betalt, om alls?
- Vilka system måste produkten prata med?
- När måste den vara ute, och varför just det datumet?
En bra offert säger vad som ingår, vad som inte ingår, vad som kommer i version två och när ni kan räkna med att ha något att visa för användare. Om det bara står en summa saknar ni det mesta av det ni behöver för att jämföra.
Vanliga misstag som gör det dyrare
- Att bygga för mycket i första versionen. Varje funktion ni inte behöver än är kostnad och risk.
- Att bygga en prototyp som ska slängas. Då betalar ni två gånger. Bygg första versionen på samma grund som den riktiga produkten ska ha.
- Att inte äga koden. Se till att koden och databasen ligger hos er från första dagen.
- Att hoppa över mätning. Utan statistik vet ni inte vad användarna gör, och då är nästa version en gissning.
- Att välja på lägsta pris. Offerter som skiljer sig mycket åt brukar täcka olika saker.
Frilansare, byrå eller no-code?
| Passar när | Tänk på | |
|---|---|---|
| Frilansare | Ni vill ha en person som bygger hela produkten och pratar direkt med er. | En person ger bra kontinuitet, men bokad tid och semestrar spelar roll. |
| Byrå | Ni behöver ett team med flera roller, till exempel en egen designer och en projektledare. | Fler led och mer overhead. Ni pratar ofta med en projektledare snarare än med den som bygger. |
| No-code | Ni vill testa en idé snabbt utan att bygga något som ska leva länge. | Gränser för egen logik, för integrationer som BankID och för egen betalning, och ett beroende av plattformen. |
Jag är frilansare, så ta mitt svar med det i åtanke. Men jag säger gärna ifrån om no-code räcker för er idé.
Ett exempel på att börja litet: Signello började som en enda sak, att skicka en offert och få den signerad med BankID, och växte utifrån vad de första användarna bad om.