Hvad koster det at bygge en MVP?
En MVP, den mindste version af et produkt der kan teste forretningsidéen, koster normalt 320.000 DKK–1,3 mio. DKK at bygge og tager 8–14 uger. Prisen afhænger af kerneflowets størrelse, om der kræves egen backend og hvor mange integrationer der indgår. En velafgrænset MVP har ét eneste flow der beviser forretningsidéen; resten bygges når antagelserne er testet.
En MVP, minimum viable product, er den mindste version af et produkt der kan teste forretningsidéen på rigtige brugere. Prisen afgøres næsten udelukkende af én ting: hvor disciplineret “mindste” bliver tolket. Her er prisniveauet i 2026 og metoden der holder det nede.
Prisniveauet: 320.000 DKK–1,3 mio. DKK på 8–14 uger
| Niveau | Typisk pris | Eksempel |
|---|---|---|
| Afgrænset MVP | 320.000–530.000 DKK | Ét flow på nettet, standardkomponenter, færdige tjenester til login og betaling |
| MVP med egen backend | 530.000–850.000 DKK | Konti, datalagring, notifikationer og en minimal admin-brugerflade |
| MVP med app og integrationer | 850.000 DKK–1,3 mio. DKK | iOS/Android, MitID eller betaling, kobling til eksterne systemer |
Tidsrammen er 8–14 uger fra start til et produkt i drift. Tager planen længere tid end det, er det som regel et tegn på at scopet ikke længere er en MVP, men en første version af det hele.
Metoden: ét kerneflow der beviser forretningen
En god MVP bygges omkring ét enkelt spørgsmål: Hvad er det mindste flow der beviser at forretningen fungerer? For en bookingtjeneste: finde en tid, booke, betale. For en markedsplads: sætte noget til salg, finde, købe. Alt det der ikke kræves for at en rigtig bruger kan gennemføre det flow, og for at rigtige penge skifter hænder, må vente.
Det lyder indlysende, men det er projektets sværeste disciplin, for alt andet føles også vigtigt. Forskellen på en MVP til 430.000 DKK og en til 1,6 mio. DKK er sjældent teknikken. Det er antallet af “når vi nu alligevel er i gang”.
Det der bevidst skal skæres væk
- Admin-finesser. Den første måneds administration klares med databaseværktøjer og regneark. Adminpaneler bygges når volumen kræver dem.
- Edge cases. Sjældne særtilfælde håndteres manuelt indtil de bliver almindelige. En mail og en manuel rettelse er billigere end en uges udviklingstid.
- Perfekt design. Konsekvent, forståeligt og tillidsvækkende er nok. Designsystemet og finpudsningen kommer når flowet er valideret.
- Valgmuligheder. Indstillinger, roller, flere sprog og temaer: Alt den slags mangedobler kompleksiteten og tester intet om forretningen.
Det er ikke nærighed, det er metode. Hver krone der bliver brugt på andet end kerneflowet, er en krone der ikke tester forretningsidéen, og hvis idéen skal justeres, er hver sådan krone desuden spildt. En MVP’s afkast måles i læring pr. investeret krone.
Det der ikke må spares væk
Minimal betyder ikke sjusket. Tre ting skal holde fuld kvalitet, også i en MVP:
- Selve kerneflowet. Det er det der bliver testet. Et fejlbehæftet eller langsomt kerneflow giver falske negative svar om forretningsidéen.
- Sikkerheden. Persondata og betalinger håndteres korrekt fra dag ét; en sikkerhedshændelse i et “testprodukt” er lige så alvorlig som i et færdigt produkt.
- Målingen. Uden indbygget analyse af hvordan brugerne faktisk opfører sig, giver MVP’en ingen læring, og læring er hele pointen med investeringen.
Regneeksempel: samme idé, to scopebeslutninger
En virksomhed vil teste en bookingtjeneste. Alternativ 1: Kerneflowet (søg, book, betal med en færdig betalingstjeneste) bygges på ti uger for cirka 640.000 DKK. Administrationen klares manuelt af én person en time om dagen. Alternativ 2: det samme flow plus adminpanel, statistikvisning, kampagnefunktion og app fra dag ét, til cirka 2,7 mio. DKK og seks måneder.
Begge versioner svarer på præcis det samme forretningsspørgsmål: Booker og betaler folk? Alternativ 1 får svaret for en fjerdedel af pengene og fire måneder tidligere. Viser svaret at idéen holder, er der 2 mio. DKK tilbage til at bygge de rigtige ting for, nu på grundlag af rigtige brugerdata i stedet for gætteri.
Efter MVP’en: Regn med fortsættelsen
MVP’en er starten, ikke målet. Budgettér med iteration efter lanceringen, ofte i samme størrelsesorden som selve MVP’en i det første år, og med drift og vedligeholdelse. Hos Weapp har vi bygget digitale tjenester som Sejfa, en digital indboforsikring til unge voksne, og det er sjældent den første version der afgør det. Det er evnen til at iterere på den.
Vil du vide hvad en MVP af din idé vil koste? Kontakt os med en beskrivelse af kerneflowet, så får du et konkret prisspænd.
Ofte stillede spørgsmål
Kan man bygge en MVP for under 320.000 DKK?
Ja, hvis værktøjet må være enklere: En klikbar prototype til 53.000–160.000 DKK eller en no-code-løsning kan teste meget. Et kodet produkt i drift i professionel kvalitet er derimod svært at presse under 320.000 DKK. Så forsvinder der som regel test, sikkerhed eller den kvalitet der gør testen troværdig.
Hvad indgår ikke i et MVP-budget?
Regn med omkostninger uden for udviklingen: konti til app-butikkerne, domæner, drift og tredjepartstjenester samt markedsføring for at få brugere til testen. En MVP uden brugere beviser ingenting, så budgettér med at nå målgruppen. Det bliver oftere glemt end nogen udviklingspost.
Skal MVP’en bygges i samme teknologi som det færdige produkt?
Helst ja. Bygges MVP’en i en stack der kan bære videre, kan den videreudvikles til det rigtige produkt i stedet for at blive skrevet om. En omskrivning efter en vellykket validering betyder at du betaler for det samme produkt to gange, og det er sjældent besparelsen i første fase værd.
Hvad sker der hvis MVP’en viser at idéen ikke holder?
Så har den gjort sit arbejde. Pointen med at teste med en afgrænset version er at få svaret for hundredtusindvis af DKK i stedet for millioner. Ofte er svaret heller ikke nej, men "ikke sådan her": Data fra MVP’en viser hvad der skal justeres før næste forsøg.
Er en MVP det samme som en betaversion?
Nej. En beta er et næsten færdigt produkt der bliver testet for fejl og stabilitet før lanceringen. En MVP er bevidst minimal og findes for at teste om forretningsidéen holder. Den stiller spørgsmålet "Skal det her bygges?" mens betaen stiller spørgsmålet "Er det klar?".