Sådan bygger jeg en MVP: min proces uge for uge

Min MVP-proces består af to dele: et kort, betalt forprojekt til fast pris, hvor vi sammen afgrænser den mindste version der kan bevise din idé, og en byggefase med en demo hver uge, indtil produktet er i hænderne på rigtige brugere. Herunder får du hele planen uge for uge, hvad du selv skal bidrage med, og hvor tidsplaner typisk skrider.

Eksemplet tager udgangspunkt i en typisk SaaS-MVP med brugerkonti, et par kernefunktioner og abonnementsbetaling. Din kan blive kortere eller længere, men rækkefølgen er den samme.

Den korte version: ugeplanen på én side

Beslutningsreglen er enkel: hvis en funktion ikke er nødvendig for at din første kunde kan få løst sit problem og betale for det, hører den ikke hjemme i uge 1-8. Otte byggeuger er ikke et magisk tal. Et produkt med ét kerneforløb og uden betaling kan være færdigt på den halve tid, mens mange integrationer, flere brugerroller eller en native app trækker i den anden retning. Hvad en kortere eller længere plan betyder for budgettet, kan du se i min gennemgang af hvad en MVP koster.

Det sværeste sjældent er koden. Det er at holde fokus på det ene problem produktet skal løse. Den side af sagen har jeg skrevet om i fra idé til SaaS: valg og prioriteringer.

Uge 0: forprojektet, hvor omfang og pris bliver låst

Det meste af det der afgør om en MVP lykkes, bliver besluttet før der skrives kode. Derfor starter jeg større projekter med et betalt forprojekt til fast pris. Det er kort, men det er her de vigtigste beslutninger bliver truffet:

1. Vi starter med målet. Hvem har problemet, hvordan løser de det i dag, og hvad skal være sandt efter lanceringen før du kalder MVP'en en succes? Et godt mål kan måles, fx "ti betalende kunder" eller "fem virksomheder der bruger produktet hver uge".
2. Vi tegner det ene kerneforløb: vejen fra en ny bruger opretter sig, til vedkommende har fået løst sit problem for første gang. Alt andet kommer i anden række.
3. Vi sorterer alle idéer i tre bunker: skal med, kan vente og skal ikke laves. Den midterste bunke bliver næsten altid den største, og det er et sundt tegn.
4. Jeg laver den tekniske plan: datamodel, hosting i EU, betaling, integrationer, og hvad der kan købes færdigt i stedet for at blive bygget fra bunden.
5. Du får en skriftlig afgrænsning, skitser af de vigtigste skærme, en ugeplan med milepæle og en fast pris for byggefasen.

Forprojektet er dit. Du betaler for det, så du kan tage afgrænsningen med til en anden udvikler, hvis du hellere vil det. Det gør beslutningen om at gå videre lettere for os begge, fordi du ikke binder dig til hele byggeriet på et løst grundlag.

Det generelle forløb i et samarbejde med mig, også når det ikke handler om en MVP, har jeg beskrevet i fra første opkald til lancering.

Uge 1-2: fundament og første klikbare version

De første to uger går med det du ikke kan se, men som resten af produktet står på. Ved udgangen af uge 2 kan du oprette dig og logge ind på et testmiljø (staging), og du har set skitserne blive til rigtige skærme.

1. Jeg opretter et repository (kodearkiv) i din egen GitHub- eller GitLab-konto, så koden er din fra første linje.
2. Datamodellen bliver bygget ud fra afgrænsningen. Det er den del der er dyrest at lave om senere, så den får tid.
3. Login, brugerkonti og de grundlæggende rettigheder kommer på plads.
4. Testmiljøet kommer online, og ny kode bliver sat i drift dér automatisk, så du altid kan se den nyeste version.
5. Skitserne bliver til et enkelt, konsekvent design bygget på færdige komponenter. Ingen bør bruge uger på et pixelperfekt design af et produkt der endnu ikke har mødt en bruger.

Den første demo er sjældent spændende at se på: en loginside og en tom oversigt. Men den beviser at fundamentet virker, og du får din første chance for at sige "det her har vi misforstået" mens det koster minutter at rette i stedet for dage. Værktøjerne jeg arbejder med i den fase, har jeg samlet i mit værktøjsbælte som freelanceudvikler.

Uge 3-5: kernefunktionerne, én ad gangen

Nu bygger jeg det kerneforløb vi tegnede i forprojektet. Jeg tager én funktion ad gangen og gør den færdig før jeg går videre, i stedet for at have fem halvfærdige ting i luften. Hver uge slutter med en demo af det nye, og du får et par dage til selv at klikke rundt og give feedback.

Det er også her nye idéer dukker op. Det er positivt, for det betyder at du ser produktet med friske øjne. Men det er samtidig den største trussel mod tidsplanen. Derfor har jeg en fast regel:

Jeg skriver automatiske tests til de dele hvor fejl gør mest skade, typisk betaling, rettigheder og alt der regner med penge. Ikke alt skal testes i en MVP, men det der kan koste dig kunder eller penge, skal.

Midt i perioden gør vi status: er vi på plan, og holder prioriteringen stadig? Har noget vist sig sværere end forventet, er det her du hører det. Ikke i uge 8.

Den klassiske fælde i denne fase er at forsøge at kunne alt det konkurrenterne kan. Vil du kende faldgruberne på forhånd, har jeg samlet 10 faldgruber ved SaaS-udvikling.

Uge 6-8: betaling, rigtige brugere og lancering

Uge 6-7: betaling, admin og de første testbrugere

1. Abonnementsbetaling bliver sat op, typisk med Stripe: priser, eventuel prøveperiode, kvitteringer og moms.
2. Du får et adminpanel, hvor du kan se brugere, hjælpe dem og rette data uden at skulle ringe til mig.
3. Fejlovervågning og logning bliver sat op, så jeg ser fejl før dine brugere skriver om dem.
4. Enkel måling af hvordan produktet bliver brugt: hvor mange kommer igennem kerneforløbet, og hvor falder de fra.
5. En håndfuld testbrugere får adgang. Ikke venner og familie, men rigtige folk fra målgruppen, som du har fundet i forvejen.

Feedbacken fra testbrugerne er den vigtigste leverance i hele projektet. Det meste bliver til små rettelser, men nogle gange viser den at et forløb skal laves om. Det er langt bedre at opdage i uge 7 end tre måneder efter lanceringen.

Uge 8: lancering og overdragelse

1. Produktionsmiljøet bliver sat op med backup, overvågning og SSL, hostet i EU.
2. Privatlivspolitik og cookieinformation kommer på plads, og du sørger for databehandleraftaler med de leverandører der behandler persondata for dig. Datatilsynet har en skabelon til databehandleraftaler. Er du i tvivl om hvad du har brug for, så spørg en jurist.
3. Lanceringen går først ud til en afgrænset gruppe, fx ventelisten eller testbrugerne, frem for en stor offentlig lancering på dag ét.
4. Du får dokumentation, alle adgange og en kort gennemgang af hvordan produktet hænger sammen.
5. Vi lægger en plan for de næste iterationer ud fra det testbrugerne og målingerne har vist.

Efter lanceringen vælger du selv retningen: en vedligeholdelsesaftale, hvor jeg holder produktet opdateret og bygger videre, eller en overdragelse til dit eget team.

Det kræver processen af dig

En MVP bliver ikke bedre end de beslutninger der bliver truffet undervejs, og mange af dem kan kun du træffe. Regn med følgende hver uge i projektperioden:

• En fast demo på under en time, samme tidspunkt hver uge.
• Et par timer til at klikke rundt på testmiljøet og svare på spørgsmål inden for et døgn eller to.
• Én person der kan sige ja eller nej. Et projekt med tre beslutningstagere og ingen med det sidste ord går langsomt.
• Tekster, priser, betingelser og logo. Jeg kan bygge rammerne, men jeg kan ikke skrive din forretning.
• Testbrugere der er fundet inden uge 6, ikke først når produktet er færdigt.

Min vurdering er at de tre hyppigste grunde til at en MVP-tidsplan skrider, er sen feedback, idéer der sniger sig ind uden at noget andet ryger ud, og indhold der først kommer i sidste uge. Ingen af dem handler om kode, og alle tre kan du styre.

Hvornår denne MVP-proces ikke passer

Planen virker bedst til et afgrænset produkt med én klar målgruppe og en ejer der har tid. Den passer dårligt, når:

• Du endnu ikke har talt med potentielle kunder. Så er en udvikler en dyr måde at teste idéen på. Start med samtaler, en landingsside med venteliste eller en klikbar prototype i fx Figma.
• Idéen kan bevises med færdige værktøjer. Kan du teste efterspørgslen med et no-code-værktøj, et regneark og noget manuelt arbejde bag kulissen, så gør det først.
• Produktet kræver et helt hold fra dag ét, fx native apps til både iOS og Android, et webpanel og flere tunge integrationer på samme tid. Så bliver én udvikler en flaskehals, og et bureau eller et lille team passer bedre.
• Du vil have en fast pris på et større projekt uden et forprojekt. Det tilbyder jeg ikke, fordi en fast pris på et uklart grundlag ender med enten et stort risikotillæg eller en konflikt.
• Ingen hos dig har tid til den ugentlige demo og feedback.

Næste skridt: sådan gør du dig klar til forprojektet

Du behøver ikke en færdig kravspecifikation for at komme i gang. Det her er nok til et godt første møde:

Når du har det på plads, er næste skridt en snak om din idé. Hvad jeg tilbyder, og hvordan et samarbejde typisk er skruet sammen, kan du se på siden om SaaS- og MVP-udvikling.

Ofte stillede spørgsmål

Kan en MVP bygges hurtigere end på otte uger?+

Ja, hvis omfanget er mindre. Et produkt med ét kerneforløb, uden betaling og uden integrationer kan ofte bygges på få uger. Det der gør en MVP hurtig, er sjældent at udvikleren skriver hurtigere, men at der er færre funktioner og færre beslutninger. Vil du hurtigere i gang, så skær i omfanget under forprojektet i stedet for at presse tidsplanen.

Hvad sker der hvis vi undervejs opdager at idéen skal ændres?+

Så stopper vi op og prioriterer igen. Små justeringer klarer vi med byt-reglen, så tid og pris holder. Er ændringen større, fx en ny målgruppe eller et nyt kerneforløb, laver vi en ny plan og en skriftlig aftale om tid og pris før jeg bygger videre. Det er en god nyhed at opdage i uge 4 frem for efter lanceringen.

Kan jeg selv lave noget af arbejdet for at spare penge?+

Ja, og det er ofte en god idé. Du kan skrive tekster, finde testbrugere, lave handelsbetingelser og stå for supporten efter lanceringen. Det sparer timer og giver dig et bedre kendskab til dit eget produkt. Koden bør til gengæld have én tydelig ansvarlig, så der aldrig er tvivl om hvem der har lavet hvad.

Skal jeg have et færdigt design før vi starter?+

Nej. Til en MVP er skitser af de vigtigste skærme nok, og dem laver vi i forprojektet. Et enkelt, konsekvent design bygget på færdige komponenter er hurtigere og billigere, og du kan altid investere i et gennemarbejdet design når du ved hvad brugerne faktisk bruger. Har du allerede et design eller en designer, bygger jeg selvfølgelig ud fra det.

Hvad sker der efter de otte uger?+

De første uger efter lanceringen handler om fejlrettelser, feedback og små forbedringer. Derefter vælger du mellem en vedligeholdelsesaftale, hvor jeg holder produktet opdateret og bygger videre i et tempo der passer dig, eller en overdragelse med dokumentation til dit eget team. Version 2 planlægger vi ud fra data, ikke ud fra den oprindelige ønskeliste.