MVP står for minimum viable product. Der findes ingen fast dansk oversættelse, men “det mindste brugbare produkt” kommer tæt på. En MVP er en rigtig version, som rigtige brugere tager i brug, så I kan finde ud af, om idéen holder, før I bruger tid og penge på resten. Ordet siger altså mere om formålet end om omfanget. Derfor er en MVP færdig, når den har givet jer svaret, og det betyder ikke, at den er klar til at blive solgt til en kunde, der forventer et fuldt produkt. Den grænse er det, der oftest overrasker stiftere uden teknisk baggrund, og den er emnet her.
De tre ord
Minimum betyder, at alt, hvad der ikke er nødvendigt for svaret, er skåret væk. Skæringen er ofte det sværeste, og fremgangsmåden finder I i artiklen om første version.
Viable betyder levedygtig. Det, der er tilbage, skal virke hele vejen, så en bruger kan få løst sin opgave uden jeres hjælp ved skærmen.
Product betyder, at det skal i hænderne på folk, der ikke kender jer. Det er dér, læringen kommer fra.
Mangler det levedygtige, har I en demo. Mangler det mindste, har I brugt pengene, før I ved noget.
Det, ordet forveksles med
- En demo viser, hvordan det kan komme til at virke. Ingen bruger den til noget rigtigt, så den kan vise interesse, men sjældent adfærd.
- En prototype besvarer, om brugerne forstår idéen. Samme artikel gennemgår forskellen, også til proof of concept.
- Fase 1 i en fast plan er noget andet. Ligger resten allerede fast, er der intet at lære, og så er ordet MVP brugt om en leverance.
- Den billige udgave af det hele er alle funktioner i halv kvalitet. Den giver sjældent et klart svar, for når brugerne falder fra, ved I ikke hvorfor.
Når leverandøren tilbyder en MVP-løsning
Ordet står ofte i tilbud fra udviklingshuse. Det kan også dække over en mindre leverance med et moderne navn, så stil fire spørgsmål:
- Hvad skal denne version vise os, og hvordan måler vi det?
- Hvad er bevidst udeladt, og hvad er blot ikke nævnt?
- Hvem ejer koden, kontiene og domænet, når den er leveret? Se ejer I selv koden, domænet og cloudkontoen?.
- Hvad sker der, hvis svaret er ja? Skal versionen bygges videre, eller skal den skrives om?
Selve forberedelsen er beskrevet i artiklen om tilbud på en app.
Et tænkt eksempel
En stifter vil lave en app, hvor små vognmænd kan få underskrift på leveringer. Drømmen rummer ruteplan, fakturering, kundeportal og kobling til økonomisystemer. Det, stifteren ikke ved, er, om chaufførerne vil bruge en app i kulden ved rampen. MVP’en bliver derfor én ting: chaufføren vælger leveringen, kunden skriver under på telefonen, og vognmanden får en PDF på mail. Tre vognmænd bruger den i to måneder, og stifteren retter fejl samme dag.
Testen lykkes. Chaufførerne bruger appen, og to vognmænd vil betale. Hvis stifteren nu sender den til tyve nye vognmænd, sker der noget andet. Ingen af dem har stifterens mobilnummer, og ingen aftale siger, hvad der sker, hvis appen er nede mandag morgen. Det er præcis her, grænsen går.
Hvor grænsen går til et produkt, I kan sælge
En MVP kan sagtens have betalende brugere. Grænsen ligger ved løftet. Under testen ved brugerne, at de er med i et forsøg. Når I sælger produktet, regner kunden med det i sin hverdag, og så skal fem ting være på plads.
Aftalen. Der skal være vilkår, der siger, hvad kunden køber, hvad I lover, og hvordan samarbejdet slutter. Sælger I en SaaS, gælder Data Act’s krav til aftalen om skift, eksporterbare data, opsigelse og overgangsperiode. Testtjenester er blandt undtagelserne, men om netop jeres pilot kan regnes for det, er et spørgsmål til en advokat. Se jeres SaaS skal kunne forlades.
Driften. Nogen skal opdage, at produktet er nede, og kunne rette det, også når stifteren er på ferie. Hvad der følger efter første version, står i første version er leveret.
Supporten. Kunderne skal vide, hvor de henvender sig, og hvornår de får svar. Stifterens telefon vokser ikke med kunderne.
Sikkerhed og data. Backup, adgange og adskillelse af kundernes data skal være i orden, så snart der kommer rigtige data ind, altså allerede i MVP’en. Forskellen ved salg er, at nogen nu spørger og vil have det skriftligt, se kundens spørgeskema om produktet.
Reglerne. Vokser MVP’en til en app, kan den være et produkt efter Cyber Resilience Act, også når den leveres uden betaling som led i kommerciel aktivitet. Hovedkravene gælder fra 11. december 2027, og vurderingen hører med, før I lancerer bredt. Se NIS2 og CRA.
Seks spørgsmål før det første rigtige salg
Svar ja eller nej sammen med den, der bygger produktet:
- Kan en ny kunde komme i gang uden jeres personlige hjælp?
- Kan I love noget om oppetid og svartid, som I faktisk kan holde?
- Kan I svare skriftligt om backup, adgange og hvor data ligger?
- Kan kunden opsige og få sine data med?
- Kan en anden end den ene udvikler rette en fejl?
- Ved I, hvad det koster at drive produktet for én kunde? Se de tekniske nøgletal.
Hvert nej er et punkt til planen, og kunden skal vide, hvad I lover.
Hvad gør I nu?
Skriv i én sætning, hvad jeres version skal vise, og hvem der skal bruge den. Aftal, hvad der skal ske ved et ja og ved et nej, og skriv ned, om koden skal bygges videre. Det valg hænger sammen med teknologivalg til MVP’en.
Mangler I en, der kan stå for den del, er det en typisk opgave for en fractional CTO. Når Nielco IT tager rollen, handler opgaven om ledelse, leverandører, teknologi og team, mens jeres udviklere eller udviklingshus står for koden. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At sælge en test som et færdigt produkt · kunden køber et løfte, I endnu ikke kan holde.
- At kalde en fast leverance for en MVP · der skal være noget at lære.
- At vente på det perfekte · en MVP, ingen bruger, svarer ikke på noget.
- At lade versionen leve videre uden en beslutning · så bliver testen til produktet ved et tilfælde.
Det skal I kræve af den eksterne
- ☐ En kort forklaring på, hvad versionen skal vise, skrevet uden fagord.
- ☐ En liste over det, der er udeladt, og hvad det betyder ved salg.
- ☐ En plan for, hvad der skal ske efter svaret.
- ☐ Klar besked om, hvem der bygger, og hvem der leder.
Kilder
- Digitaliseringsstyrelsen om cloudtjenester i dataforordningen: krav til aftalen og undtagelser.
- Kommissionens vejledning C(2026) 5252: ikke bindende, afsnit 2 og nr. 40 om levering i erhvervsmæssig sammenhæng. Datoer: Kommissionens side om CRA.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ikke-teknisk stifter: sådan kommer produktet i gang · Fra AI-bygget prototype til produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
