Hvad koster en MVP? Realistiske priser, og hvad der driver dem (2026)

En MVP, altså den mindste version af dit produkt som rigtige kunder kan bruge, koster typisk 100.000-160.000 kr. for en smal første version og 250.000-400.000 kr. for en SaaS med abonnementsbetaling når en erfaren freelancer bygger den. Prisen på MVP-udvikling styres mest af hvor mange brugertyper, integrationer og betalingsflows første version skal have, ikke af hvor stor idéen føles.

Jeg er selv freelanceudvikler og bygger den slags løsninger, så læs med det forbehold. Nedenfor får du tre eksempler med omfang, timer og pris, og jeg fortæller også ærligt hvornår du slet ikke skal betale for en MVP endnu.

Den korte version: tre prisniveauer

Timerne er mine grove skøn for en erfaren udvikler der bygger i et moderne framework som Laravel og genbruger standardkomponenter hvor det er muligt. Jeg regner med 1.000 kr. i timen, fordi det er et rundt tal midt i det spænd på 800-1.200 kr. som LønRadar angiver for senior it-konsulenter i 2026. Det er ikke min pris, men et regnestykke du selv kan skalere: betaler du 800 kr. i timen, trækker du 20 % fra.

Hvad en normal timepris er i Danmark, har jeg skrevet mere om i indlægget om timepriser for freelanceudviklere. Vil du se priser på andre typer projekter end MVP'er, finder du dem i den samlede prisguide til softwareudvikling.

Tre eksempler på en MVP med omfang, timer og pris

Eksemplerne er typiske projekttyper, ikke konkrete kundeprojekter. De viser hvor timerne går hen, så du kan sammenligne med din egen idé og med de tilbud du får.

Eksempel 1: Kundeportal til en servicevirksomhed (100-160 timer)

En servicevirksomhed vil lade sine erhvervskunder oprette opgaver og følge status online i stedet for via mail og telefon. Der er én brugertype udefra, og virksomhedens egne medarbejdere arbejder i en enkel administration. Der er ingen betaling i systemet, for fakturaen sendes fra regnskabsprogrammet som hidtil.

To ting holder prisen nede: der er kun én slags bruger udefra, og ingen penge flytter sig gennem systemet. Login er ikke længere en stor post. Laravels officielle starter kits leverer login, registrering, nulstilling af adgangskode og tofaktorgodkendelse fra start, så timerne kan gå til det der er særligt for din forretning.

Eksempel 2: SaaS-MVP med månedligt abonnement (250-400 timer)

Et planlægningsværktøj til små virksomheder der sælges pr. måned. Hver kunde er en virksomhed med flere brugere som skal kunne invitere kolleger, have forskellige rettigheder og betale med kort. Produktet har 1-2 kernefunktioner, fx vagtplan og fraværsregistrering.

Springet fra eksempel 1 skyldes ikke kun flere funktioner. Når mange virksomheder deler det samme system, skal hver eneste side sikre at kunde A aldrig ser kunde B's data. Det tager tid i både kode og test, og det er ikke der du skal spare. Betaling er også mere end en knap: prøveperioder, opsigelser, afviste kort og fakturaer skal håndteres.

Vil du se hvad det koster at drive og videreudvikle en SaaS efter lanceringen, har jeg lavet et linje-for-linje-budget for en SaaS.

Eksempel 3: Markedsplads med booking og betaling (400-650 timer)

En platform hvor kunder finder og booker lokale udbydere, fx personlige trænere eller håndværkere, og hvor platformen tager et gebyr pr. booking. Der er to brugertyper med hver deres flow, og pengene skal fordeles mellem parterne.

Markedspladser er dyre fordi det meste skal bygges to gange: én oplevelse til køberen og én til udbyderen. Betalingsdelen kan lægges over på en færdig løsning som Stripe Connect, der er lavet til netop platforme hvor penge skal fordeles mellem flere parter. Mit klare råd er at bygge software til den ene side af markedet og håndtere den anden side manuelt de første måneder. Det alene kan fjerne en stor del af timerne.

Seks ting der driver prisen på en MVP op

• Hver ny brugertype (kunde, medarbejder, udbyder, administrator) betyder egne skærme, egne regler og egne test. Det er den enkeltfaktor der flytter prisen mest.
• En integration til fx e-conomic, et CRM eller et lønsystem koster groft skønnet fra 15 til over 60 timer. Det afhænger af hvor god dokumentationen er, og om data skal synkroniseres begge veje. MitID-login går typisk gennem en mellemmand (en såkaldt broker) og er en integration for sig.
• Et betalingslink er hurtigt at sætte op. Abonnementer med prøveperiode, rabatkoder og opgradering midt i en periode er det ikke.
• Et unikt design tegnet i Figma før udviklingen kan nemt koste lige så meget som en kernefunktion. Til en MVP er et gennemarbejdet komponentbibliotek som regel nok.
• Skal produktet ligge i App Store og Google Play fra første dag, bygger du reelt et ekstra produkt. En webapp der virker godt på mobilen, er næsten altid nok til at teste idéen.
• Langsomme beslutninger overses oftest. Går der en uge mellem hvert svar, eller skal tre personer godkende hver skærm, stiger timetallet. Én beslutningstager med tid i kalenderen er en reel besparelse.

Hvornår du ikke skal betale for en MVP endnu

Det lyder mærkeligt fra en udvikler, men mange idéer bør testes for langt mindre end 100.000 kr. før der skrives en eneste linje kode. Er du ikke sikker på at nogen vil betale, så start her:

• Lav en landingsside med venteliste. Beskriv produktet, sæt en pris på, og mål hvor mange der skriver sig op.
• Lav en klikbar prototype i Figma. Vis den til ti potentielle kunder og se hvor de går i stå.
• Lever ydelsen i hånden med regneark og mail til de første kunder. Det kaldes en concierge-MVP, og den afslører hurtigt hvad der faktisk skal automatiseres.
• Byg en prototype med et AI- eller no-code-værktøj som Lovable eller Bubble. Det er fint til at teste efterspørgsel, men ikke til persondata eller betaling uden en grundig gennemgang.

Mangler du finansiering, så undersøg om du kan få tilskud til at udvikle din MVP før du bruger dine egne penge.

Du skal heller ikke vælge en freelancer som mig hvis du har brug for brand, design, tekst og markedsføring på samme tid. Det er et bureau bedre rustet til. Og har du brug for et helt hold der bygger i fuld fart i et halvt år, bliver én udvikler en flaskehals.

Sådan får du prisen ned uden at spare på kvaliteten

1. Skær funktioner væk før udviklingen starter. Sortér alt i "skal med", "bør med" og "senere". Alt i "senere" er penge sparet, og meget af det viser sig aldrig at blive savnet. Jeg har beskrevet metoden i guiden til at afgrænse en MVP.
2. Gør det manuelt bag kulissen. Send fakturaer i hånden til de første 10-20 kunder i stedet for at bygge et abonnementssystem. Godkend nye brugere manuelt i stedet for at bygge regler for det.
3. Brug standardkomponenter. Færdige knapper, formularer og tabeller ser professionelle ud og sparer mange designtimer. Et unikt udtryk kan komme når du ved hvad brugerne faktisk bruger.
4. Køb det der ikke er din forretning. Betaling, afsendelse af mails og login med Google eller Microsoft findes som færdige tjenester. Byg kun det der gør dit produkt anderledes.
5. Byg en webapp, ikke en native app. Den kan bruges på mobil, tablet og computer fra én kodebase.
6. Betal for et afgrænset forprojekt først. Et forprojekt til fast pris lægger omfang, skærme og risici fast, så estimatet bliver langt mere præcist, og dyre misforståelser bliver fanget før de bliver til kode. Jeg arbejder selv sådan ved større projekter og har skrevet om hvad en discovery-fase koster, og hvorfor den betaler sig.

Udgifterne efter lanceringen

Prisen på selve udviklingen er ikke hele regningen. Når MVP'en er i luften, kommer der løbende udgifter:

• Hosting og drift koster groft skønnet et par hundrede til et par tusinde kroner om måneden for en MVP med få brugere, afhængigt af udbyder, database og backup.
• Stripe tager 1,5 % + 1,80 kr. pr. betaling med standardkort fra EØS, og abonnementsmodulet Billing koster 0,7 % af volumen hvis du betaler efter forbrug, ifølge Stripes danske prisside.
• Tredjepartstjenester som afsendelse af mails, fejlovervågning og eventuelt en MitID-broker har hver deres abonnement.
• Framework og pakker skal opdateres, og sikkerhedshuller skal lukkes, også selvom produktet står stille.
• Til videreudvikling er min tommelfingerregel at holde 30-50 % af MVP-budgettet tilbage til de første tre til seks måneder efter lanceringen. De vigtigste ændringer kommer når rigtige brugere tager produktet i brug, og dem vil du gerne kunne nå at lave.

Næste skridt: fra idé til et prisoverslag du kan bruge

1. Skriv dine brugertyper ned og det ene flow som MVP'en skal kunne.
2. Sortér alle andre funktioner i "bør med" og "senere".
3. Sammenlign med de tre eksempler ovenfor, og find det niveau der ligner dit projekt mest.
4. Få et groft timeskøn fra en eller to udviklere, og bed om at se timerne fordelt på dele som i tabellerne.
5. Start med et afgrænset forprojekt til fast pris før du skriver under på hele udviklingen.

På siden om SaaS-udvikling kan du se hvordan jeg griber en MVP an fra forprojekt til lancering. Du ejer koden fra første dag, og du taler direkte med mig, der skriver den.

Ofte stillede spørgsmål

Kan man få lavet en MVP for under 50.000 kr.?+

Ja, men kun hvis den er meget smal eller er en prototype bygget med no-code- eller AI-værktøjer. 50.000 kr. svarer til omkring 50 timer hos en erfaren freelancer. Det rækker til én enkel funktion bag et login, men ikke til betaling, roller eller integrationer. Med så lille et budget får du som regel mest ud af at teste efterspørgslen først og bygge bagefter.

Er fast pris eller timepris bedst til en MVP?+

En kombination virker ofte bedst. Et forprojekt til fast pris gør omfanget så klart at selve udviklingen også kan prissættes fast eller i faste faser. Er omfanget stadig uklart, er timepris med et månedligt loft mere ærligt end en fast pris med en stor risikobuffer regnet ind. Spørg altid hvordan ændringer undervejs bliver prissat før du skriver under.

Kan jeg bygge MVP'en selv med AI-værktøjer?+

Ja, til en prototype kan det være en rigtig god idé. Værktøjer som Lovable og Bolt kan hurtigt lave noget du kan vise til potentielle kunder. Udfordringen kommer når rigtige kunder og rigtige data skal ind. Sikkerhed, adgangskontrol, betaling og backup kræver typisk en udvikler der gennemgår koden og ofte skriver dele af den om før den er klar til drift.

Hvem ejer koden til min MVP?+

Det bør være dig, og det skal stå i aftalen. Når en freelancer eller et bureau skriver koden, følger rettighederne ikke automatisk med betalingen, så kontrakten skal overdrage dem til dig. Sørg også for at koden ligger i dit eget repository fra første dag. Hos mig ejer kunden koden fra start. Det er ikke juridisk rådgivning, så få kontrakten tjekket hvis der står meget på spil.