Kort svar
Vad ska ingå i en app-MVP?
En färdig app med få funktioner — inte en halvfärdig app med många. Det betyder: ett användarflöde som fungerar hela vägen, riktig data, inloggning om appen kräver det, publicering i butikerna och något sätt att se hur appen används.
Allt som inte behövs för att besvara frågan "använder någon det här?" hör hemma i version två. Vi bygger MVP:er från 60 000 kr, oftast på fyra till åtta veckor.
Definitionen som faktiskt hjälper
Formulera en mening: "Vi vet att idén håller om X antal användare gör Y inom Z veckor." Allt i appen som inte hjälper någon att göra Y är utanför omfattningen. Den meningen är ett skarpare verktyg än vilken funktionslista som helst, eftersom den ger ett svar på varje diskussion om vad som ska med.
Vad som alltid ska med
- Ett komplett huvudflöde — från start till det ögonblick användaren fått ut sitt värde.
- Riktig data i en riktig backend. Låtsasdata döljer exakt de problem en MVP ska hitta.
- Inloggning om appen har personlig data, annars inte. Ett konto är ett hinder tills det ger något.
- Grundläggande felhantering: ingen täckning, fel lösenord, tomt läge på en lista.
- Publicering på båda plattformarna. Med en delad kodbas kostar den andra plattformen lite extra.
- Enkel användningsstatistik, så att beslutet efteråt bygger på siffror och inte på magkänsla.
Vad som nästan alltid kan vänta
| Funktion | Varför den kan vänta |
|---|---|
| Adminpanel | Under de första veckorna räcker det att vi ändrar direkt i databasen |
| Betalningar | Bygg först något folk vill ha. Betalflöden är sällan det som stoppar användandet |
| Sociala funktioner | Kräver kritisk massa som en MVP per definition inte har |
| Flera språk | Ett språk först. Översättning är billig senare, dyr att underhålla tidigt |
| Offline-stöd | Bara om målgruppen faktiskt arbetar utan täckning |
| Pushnotiser | Behövs sällan innan det finns något att notifiera om |
| Mörkt läge | Trevligt, men flyttar aldrig ett beslut |
Exempel: en MVP för 60 000 kr
En bokningsapp för en mindre verksamhet. Innehåller: inloggning med e-post, en lista över lediga tider, bokning, mina bokningar, avbokning, bekräftelsemejl. Byggd i React Native med Supabase som backend, publicerad i båda butikerna. Fyra till fem veckor.
Det som inte ingår: betalning, adminpanel, notiser, kalendersynk, flera lokaler. Var och en av dem är mellan en och tre veckors arbete, och samtliga går att lägga till efteråt utan att något skrivs om.
Kvalitet ska inte skäras bort
Det får vara få funktioner — inte dåliga
En MVP med tre skärmar som känns snabba och genomtänkta ger användbara svar. Femton skärmar som halvfungerar ger bara ett svar: att appen är seg. Vi lägger hellre tid på laddningstider, tomma lägen och en genomarbetad huvudskärm än på fler menyval.
Koden ska hålla
En MVP är inte en prototyp som slängs. Det vi bygger i version ett är samma kodbas som lever vidare. Genvägar tas i omfattning, aldrig i arkitektur — annars betalar du för samma app två gånger. Så här går det till hos oss: MVP-utveckling på 4–8 veckor.
Efter lanseringen
Boka in ett beslutstillfälle redan när projektet startar, typiskt fyra till sex veckor efter lansering. Titta på siffrorna, prata med tio användare och besluta: bygga vidare, ändra riktning eller lägga ner. En MVP utan ett sådant beslutstillfälle blir bara en liten app som ingen vågar avveckla. Behöver du hjälp att sätta omfattningen, läs om hur en användbar kravspecifikation ser ut.
Testet på en välavgränsad MVP: kan du beskriva vad appen gör i en mening, utan att använda ordet "och" mer än en gång? Går det inte är omfattningen fortfarande för stor.
Vad du får med dig
- En MVP är komplett men liten — inte ofärdig.
- Formulera en mätbar mening om vad som ska bevisas, och skär bort allt som inte bidrar.
- Riktig backend och riktig publicering ska med; adminpanel, betalningar och notiser kan oftast vänta.
- Spara på omfattningen, aldrig på arkitekturen.