Hur lång tid tar det att bygga en MVP?
Av CodexierPublicerad 6 min läsning
Det ärliga svaret är 'veckor om omfattningen hålls, månader om den inte gör det'. Själva bygget är sällan den långsamma delen av en MVP; det långsamma är besluten före och ändringarna under. Den här guiden ger en realistisk bild vecka för vecka, vad varje fas kräver av grundaren och de beslut som drar ett projekt förbi sitt datum.
Förstudie och avgränsning
Förstudien är där tidsplanen egentligen avgörs. Dess uppgift är att göra en idé till ett kärnflöde: den enda vägen en användare tar från att komma in till att få värdet. Allt som inte ligger på den vägen skrivs ner till senare. Resultatet är ett kort avgränsningsdokument, en lista över integrationer (BankID, Stripe, Fortnox, en mejlleverantör) och ett beslut om vad 'klart' betyder vid lansering. En grundare som kommer med de tre redan utkastade sparar en vecka.
Design och prototyp
Före kod, en klickbar prototyp av kärnflödet. Den kostar dagar, inte veckor, och den är det billigaste stället att upptäcka att onboardingen har ett steg för mycket eller att översikten besvarar fel fråga. Visa den för fem personer som liknar era användare. Att ändra en vy i Figma tar en timme; att ändra den när den är byggd och kopplad till en databas tar en dag.
- Skisser av varje vy i kärnflödet, i ordning
- En klickbar prototyp från registrering till första värde
- Skriftliga anteckningar från fem korta testsessioner
- Designen hålls minimal: ett typsnitt, en komponentuppsättning, inga egna illustrationer än
Bygg i korta cykler
Bygget löper i cykler om en eller två veckor, var och en avslutad med något du kan klicka på. Den rytmen är ingen metodpreferens; den är mekanismen som håller tidsplanen ärlig. En veckodemo blottar missförstånd efter fem dagar i stället för efter fem veckor, och den ger grundaren en naturlig plats att ställa frågor utan att avbryta arbetet varje eftermiddag.
| Cykel | Vad som oftast byggs | Vad du behöver göra |
|---|---|---|
| 1 | Projektskelett, inloggning, databas, driftsättningsflöde | Bekräfta inloggningsmetod (e-post, BankID, Google) och domän |
| 2 | Kärnflödets datamodell och första vyer | Leverera riktig exempeldata, inte lorem ipsum |
| 3 | Kärnflödet från början till slut, med grova kanter | Klicka igenom det själv; anteckna vad som förvirrar |
| 4 | Betalningar eller den viktigaste integrationen, adminvy | Sätt upp Stripe- eller Fortnox-kontot i företagets namn |
| 5 | Mejlflöden, felhantering, specialfall från din testning | Testa med två eller tre välvilliga användare |
| 6 | Finputs, prestanda, säkerhetschecklista, lanseringsförberedelser | Skriv villkor och integritetspolicy, eller godkänn våra |
Sex cykler är en typisk medelstor MVP. Ett verktyg med ett enda flöde kan klara sig på fyra; en tvåsidig marknadsplats hamnar sällan under åtta.
Test och lansering
Sista fasen är kortare än grundare fruktar och viktigare än de väntar sig. Den täcker en säkerhetsgenomgång (behörigheter, validering av indata, hemligheter ut ur koden), en prestandakontroll på realistisk data, en GDPR-kontroll av vad som lagras och varför, och lansering på den riktiga domänen med övervakning och säkerhetskopior påslagna. Sedan de första riktiga användarna, i en liten grupp, medan någon bevakar felloggarna.
Mjuk lansering
Tio till femtio inbjudna användare i två veckor. Tillräckligt för att hitta problemen, få nog för att be om ursäkt personligen.
Publik lansering
Först efter rättningarna från den mjuka lanseringen. Själva lanseringsdagen är en marknadshändelse, inte en teknisk.
Första månaden efter
Budgetera för den. De första riktiga användarna ger den mest värdefulla ändringslistan ni någonsin får, och någon måste agera på den.
Det som förlänger tidsplanen
Bygget halkar nästan aldrig för att kodandet gick långsamt. Det halkar av fem skäl, och alla fem är beslut. Omfattning som läggs till mitt i bygget ('när vi ändå håller på') startar om designen av vyer som redan var klara. Integrationer med tredje part vars dokumentation är tunn eller vars testmiljö beter sig annorlunda än produktionen. Beslut som väntar på ett veckomöte i stället för ett svar samma dag. Innehåll och material (texter, villkor, logotyp, produktdata) som kommer sent. Och perfektionism på vyer ingen använt än.
När ni inte ska starta bygget än: om ni inte kan namnge det enda kärnflödet, om ni inte pratat med tilltänkta användare, eller om budgeten bara täcker bygget och inget för månaden efter. I de fallen är planeringsfasen för sig, eller helt enkelt fler kundsamtal, den bättre utgiften. Är omfattningen klar har prissidan de fasta priserna och leveranstiderna, och ett kort samtal säger ärligt vilken av de fyra faserna ert projekt faktiskt befinner sig i.
- MVP-utveckling och driftsättningBygge till fast pris av en avgränsad MVP i korta cykler, driftsatt på er domän med övervakning och överlämning.
- MVP-planering och arkitekturFörstudien för sig: omfattning, kärnflöde, integrationer och en byggplan ni kan ta med er vart som helst.
- Boka ett kostnadsfritt 15-minuterssamtalBeskriv idén och vad som finns i dag; vi säger vilken fas ni är i och hur många veckor resten borde ta.
Vanliga frågor
Kan en MVP byggas på två veckor?
En prototyp kan det, och ett mycket smalt verktyg utan betalningar eller integrationer kan det ibland. En produkt med registrering, ett kärnflöde, betalning och en adminvy är inte ett tvåveckorsprojekt om den ska ta emot riktiga kunder. Var vaksam på offerter som lovar det; tiden dyker oftast upp igen som buggar efter lansering.
Vad kan jag som grundare göra för att hålla tidsplanen?
Svara på frågor samma dag, leverera riktigt innehåll och exempeldata tidigt, sätt upp tredjepartskonton (Stripe, domän, e-post) i eget namn innan bygget startar, och säg nej till dina egna 'när vi ändå håller på'-idéer tills efter lansering. Grundarens svarstid är den enskilt största faktorn vi ser.
Går det snabbare med no-code?
För ett enkelt flöde, ja, och det är värt att överväga. För allt med egen logik, BankID eller data ni vill äga och flytta senare, går tiden som sparas i början ofta åt senare till att arbeta runt plattformen. Rätt fråga är inte bara hastighet utan vad som händer i månad sex.
Hur lång tid tar det att bygga en tvåsidig marknadsplats?
Längre än en produkt med ett flöde, eftersom det finns två användartyper, två onboardingflöden, matchning eller sök och oftast betalningar som delas mellan parter. Åtta till tolv cykler är ett realistiskt spann för en första version. Många marknadsplatsgrundare lanserar ena sidan manuellt först, vilket kortar bygget avsevärt.
Vill du ha en realistisk tidsplan för din idé?
Femton minuter: du beskriver produkten och vad som finns i dag, vi säger vilken fas du är i, hur många veckor ett fokuserat bygge borde ta och vad som skulle förlänga det.
Boka ett kostnadsfritt 15-minuterssamtal