Förbered detta innan MVP-projektet startar
Av CodexierPublicerad 5 min läsning
De första veckorna i ett MVP-projekt går ofta förlorade på sådant som inte har med kod att göra: ingen kan besluta, domänen tillhör en tidigare medgrundare, Apples utvecklarkonto är fortfarande under granskning, logotypen finns bara som skärmdump. Var och en blockerar en specifik uppgift, och tillsammans skjuter de lanseringen veckor framåt. Den här guiden är förberedelselistan vi skickar till kunder inför en uppstart, så att bygget startar dag ett.
Beslutsfattare och tillgänglighet
Ett MVP-bygge producerar ett beslut om dagen: vilket av två flöden, om ett fält är obligatoriskt, vad som händer vid ett fel. Väntar de besluten på ett veckomöte väntar bygget med dem. Utse en person med mandat att svara inom en dag, och kom överens om hur hen nås. Är den personen grundaren som också sköter försäljningen, blockera tiden i kalendern nu, för bygget överlever inte på luckorna mellan kundsamtal.
Användare, problem och mått på framgång
Utvecklarna behöver förstå användaren tillräckligt väl för att fatta de små besluten utan att fråga. Det kräver ingen kravspecifikation på hundra sidor; det kräver ett tydligt stycke och ett tal. Skriv ner vilka de första användarna är, problemet de har i dag, hur de löser det nu och vad de ska göra i produkten under de första tio minuterna. Välj sedan måttet som säger att MVP:n fungerar.
| Punkt | Så ser bra ut | Det som blockerar bygget |
|---|---|---|
| Första användarna | Ett namngivet segment ni kan nå: tio specifika företag eller personer | Alla i Sverige som har bil |
| Problemet i dag | Den lösning de använder nu, med dess kostnad i tid eller pengar | Ett påstående om marknadsstorlek |
| Kärnflödet | Den enda vägen från registrering till värde, i fem till åtta steg | En lista på fyrtio funktioner med samma prioritet |
| Mått på framgång | Ett tal, mätbart i produkten, med ett mål för månad ett | Tillväxt, engagemang eller traction utan definition |
Konton: domän, moln och appbutiker
Konton ska skapas av ert företag, i företagets namn, före uppstarten, med utvecklarna tillagda som medarbetare. Det här är den vanligaste orsaken till en försenad lansering och den enklaste att förebygga. Några av dem tar dagar att godkänna, och en butiksgranskning kan ingen korta.
- Domän registrerad på ert företag, med åtkomst till DNS. Kontrollera vem som faktiskt äger den om den köptes för flera år sedan.
- Moln- eller hostingkonto (till exempel Vercel, Supabase, AWS) med fakturering på ett företagskort, och ett regionbeslut för datalagring.
- Apple Developer Program och Google Play Console, ansökta nu om det finns en mobilapp; båda verifierar organisationen och kan ta tid.
- En GitHub- eller GitLab-organisation som ni äger, så att koden ligger i ert konto från första committen.
- Tjänst för transaktionsmejl, statistik, felspårning och en betalleverantör om MVP:n tar betalt, var och en i företagets namn.
- Ett delat valv i en lösenordshanterare för projektet, i stället för inloggningsuppgifter i chattmeddelanden.
Varumärkesmaterial och innehåll
Skärmar byggs runt innehåll, och platshållartext döljer problem: ett riktigt företagsnamn är längre än Lorem, ett riktigt felmeddelande behöver en riktig ton. Ni behöver ingen färdig identitet, men utvecklarna behöver delarna som finns, i användbara format.
Logotyp och färger
Logotyp som SVG, primär- och sekundärfärger som hex-värden, och typsnittet om ni har ett. En skärmdump av logotypen går inte att använda.
Ord till de första skärmarna
Produktnamnet, beskrivningen på en rad, namnen på huvudobjekten (är det ett projekt, ett ärende, en bokning?) och språket: svenska, engelska eller båda från start.
Exempeldata
Tio realistiska poster av det produkten hanterar, avidentifierade. Data med verklig form avslöjar fält, format och specialfall som specifikationen missade.
Juridisk grund: villkor och integritet
En MVP med riktiga användare är en produkt med juridiska skyldigheter från första registreringen. Inget av detta kräver en advokatbyrå för en första version, men det kräver beslut, eftersom utvecklarna bygger registrering, samtycke och radering enligt det ni bestämmer.
- Användarvillkor och integritetspolicy, utkast från mall och granskade för ert fall, publicerade före första externa användaren.
- Var personuppgifter lagras: en EU-region är det enkla svaret för en svensk produkt, och det måste väljas innan databasen skapas.
- Vilka uppgifter ni faktiskt behöver vid registrering; varje extra fält är en GDPR-fråga och ett konverteringstapp.
- Hur en användare raderar sitt konto och sina uppgifter, för det måste finnas vid lansering, inte senare.
- Företagsuppgifterna på sajten och i mejlen: juridiskt namn, organisationsnummer, kontaktadress.
- Om B2B: en mall för personuppgiftsbiträdesavtal som era kunder kan skriva under, eftersom deras inköp kommer att fråga.
När ni inte behöver den här listan: validerar ni en idé med en landningssida och en väntelista, förbered domänen, orden och integritetspolicyn och hoppa över resten tills något är byggt. Hela listan är för ett bygge med riktiga användare och riktiga data. Är ni inte säkra på att omfattningen är rätt än gör vår MVP-planering om stycket och måttet ovan till en arkitektur och en byggplan innan någon binder sig till utveckling; den prissätts på prissidan, eller boka ett samtal så säger vi vilka punkter på listan ni fortfarande saknar.
Vanliga frågor
Hur mycket av specifikationen ska vara klar före uppstarten?
Stycket om användare och problem, kärnflödet och måttet på framgång. En detaljerad specifikation av varje skärm behövs inte och är ofta skadlig, eftersom den låser beslut som borde fattas med en prototyp i handen. Uppstarten är där detaljerna tas fram.
Ska utvecklarna skapa kontona åt oss?
De kan hjälpa till, men kontona måste ägas av ert företag och betalas med ert kort. Konton skapade under en leverantörs e-post är en återkommande orsak till förlorade domäner och låsta butikskonton när samarbetet avslutas.
Vad gör vi om vi inte har logotyp eller namn än?
Välj ett arbetsnamn och en enda färg och fortsätt. Att döpa om en produkt före lansering är billigt; att vänta på en färdig identitet är dyrt. Varumärket kan läggas på under byggets sista vecka.
Behöver vi villkor och integritetspolicy för en stängd beta?
Ja, åtminstone en kort version. Betaanvändare är fortfarande användare vars uppgifter ni behandlar, och en tydlig policy från start är enklare än att lägga till samtycke i efterhand. En mall granskad för era dataflöden räcker för en beta.
Uppstart på gång och osäker på om ni är redo?
Femton minuter: vi går igenom listan med er, markerar vad som saknas och säger vad som faktiskt skulle försena bygget. Kostnadsfritt, och användbart vem som än bygger.
Boka ett kostnadsfritt 15-minuterssamtal