Appen er lanceret. Hvem tager sig af den nu?

Af Weapp · Opdateret 2025-12-19

Vedligeholdelse efter lancering omfatter fejlretning, tekniske opdateringer, support og mindre forbedringer. Et rimeligt årsbudget ligger ofte på 15–25 procent af den oprindelige udviklingsomkostning, mere hvis produktet videreudvikles aktivt. Aftalen bør definere hvad der indgår i det månedlige gebyr, hvilke svartider der gælder og hvor grænsen til videreudvikling går.

Lanceringsdagen føles som målstregen, men for produktet er den startskuddet. Fra dag ét begynder styresystemer at blive opdateret, afhængigheder at blive forældede og brugere at finde ting der burde blive bedre. Spørgsmålet er ikke om produktet skal passes, men hvem der gør det, hvad det må koste og hvordan aftalen skal se ud.

Vedligeholdelsens fire bestanddele

Fejlretning. Bugs der bliver opdaget i produktion, skal findes, prioriteres og rettes, med klare forventninger til hvor hurtigt.
Opdateringer. Nye versioner af styresystemer, sikkerhedspatches, opdaterede afhængigheder og tredjepartstjenester der ændrer deres grænseflader. Det usynlige arbejde der holder produktet i live.
Support. En der svarer når noget ser mærkeligt ud, tager imod fejlmeldinger og kan skelne brugerfejl fra rigtige fejl.
Mindre videreudvikling. Små forbedringer og justeringer der ikke berettiger et selvstændigt projekt, ofte håndteret via en timebank.

Grænsen mellem vedligeholdelse og videreudvikling er den mest almindelige kilde til misforståelser. En enkel tommelfingerregel: Vedligeholdelse holder produktet i den stand det blev lanceret i, videreudvikling gør det bedre.

Den rene drift er derimod en separat post uden for vedligeholdelsen: servere, domæner og licenser der koster penge selv når intet menneske rører produktet. Hold den adskilt fra vedligeholdelsen i budgettet. Det gør både tilbud og fakturaer lettere at gennemgå.

Hvad koster vedligeholdelsen om året?

En almindelig tommelfingerregel er 15–25 procent af den oprindelige udviklingsomkostning om året for ren vedligeholdelse. Vil I derudover udvikle produktet aktivt, kommer der et budget til videreudvikling oveni, ofte 20–40 procent af udviklingsomkostningen om året. Som månedlig aftale lander vedligeholdelse typisk på 11.000–53.000 DKK afhængigt af omfang og serviceniveau.

Et konkret regneeksempel: En app der kostede 1,3 mio. DKK at bygge, bør have et vedligeholdelsesbudget på cirka 190.000–320.000 DKK om året, altså 16.000–27.000 DKK om måneden. Er appen forretningskritisk med krav om beredskab uden for kontortid, havner I i den øvre del eller derover.

Reaktiv vedligeholdelse eller aktiv produktudvikling?

Reaktiv vedligeholdelse betyder at nogen rykker ud når noget går i stykker. Det er billigst på papiret, men produktet står stille, og den tekniske gæld vokser i det skjulte indtil en opgradering bliver et projekt i sig selv.

Aktiv produktudvikling betyder løbende kapacitet hver måned: Bugs bliver rettet, afhængigheder holdes opdaterede, og en prioriteret backlog bliver afviklet. Produktet bliver bedre i takt med at I lærer af brugerne.

Vores anbefaling er aldrig at gå under niveauet “reaktiv vedligeholdelse med et planlagt opgraderingstempo”. Er produktet vigtigt for forretningen, bør I regne på den aktive model: Forskellen kan ses på hvad produktet er værd om tre år. Der findes også mellemniveauer: Mange starter reaktivt med kvartalsvise opgraderingsvinduer og skruer op når produktet har bevist sin værdi.

Jeres egen rolle i vedligeholdelsen

En serviceaftale passer ikke sig selv. Udpeg en intern ejer der prioriterer timebanken, samler brugernes feedback og træffer beslutninger når leverandøren har brug for svar. Uden den rolle bliver timebanken brugt på det der tilfældigvis råber højest, og statusmøderne bliver en gennemgang af gamle sager i stedet for en plan fremad. Regn med nogle timer om ugen. Det er den billigste kvalitetssikring i hele opsætningen.

Sådan skruer du aftalen sammen

Definér hvad der indgår i det månedlige gebyr, og list eksempler på hvad der ikke indgår.
Fastsæt serviceniveauer for svartid og løsningstid pr. alvorlighedsgrad, og skeln omhyggeligt mellem de to begreber.
Regulér timebanken: størrelse, hvad den må bruges til og om ubrugte timer kan overføres.
Sikr ejerskabet løbende: jeres egne konti, adgang til koden og dokumentation der opdateres kontinuerligt, ikke kun ved afslutningen.
Fastlæg opsigelsesvarsel og exit: hvad der overdrages, i hvilket format og til hvilken pris.

Aftal vedligeholdelsen før lanceringen

Det bedste tidspunkt at få styr på vedligeholdelsen er før produktet går live, mens viden er frisk og incitamenterne sunde. Vi hos Weapp foretrækker at vedligeholdelsesopsætningen bliver udarbejdet som en del af udviklingsprojektet, ikke som en eftertanke når noget allerede har nået at gå i stykker. Vil du have hjælp til at fastsætte et rimeligt niveau for jeres produkt? Kontakt os, så tager vi en snak om det.

Ofte stillede spørgsmål

Indgår nye funktioner i en serviceaftale?

Normalt ikke. Vedligeholdelse holder produktet i den stand det blev lanceret i mens nye funktioner regnes som videreudvikling og prissættes i et særskilt tilbud. Mange aftaler indeholder dog en timebank der dækker mindre forbedringer. Tjek hvor grænsen går.

Hvor stor en timebank har vi brug for pr. måned?

Det afhænger af produktets størrelse og forandringstempo. Mange starter med 10–20 timer pr. måned og justerer efter et kvartal når det kan ses hvor meget der faktisk bliver brugt. Vigtigere end den præcise størrelse er vilkårene: Forhandl gerne om at ubrugte timer kan overføres.

Kan vi selv stå for vedligeholdelsen?

Ja, hvis I har udviklerkompetencer internt og løbende kan holde øje med sikkerhedsopdateringer, afhængigheder og driftsalarmer. Mange vælger en hybrid: intern første linje til support og enklere sager, og et bureau til opgraderinger, fejlretning og beredskab.

Hvad sker der hvis vi helt springer vedligeholdelsen over?

Produktet holder ikke op med at virke med det samme, men det forfalder: Styresystemer og afhængigheder bliver opdateret, sikkerhedshuller bliver opdaget, og tredjepartstjenester ændrer deres vilkår. Efter et par år uden tilsyn venter der ofte et dyrt efterslæb, og at indhente det koster mere end løbende vedligeholdelse ville have gjort.

Skal vedligeholdelsen varetages af det bureau der byggede produktet?

Nej. Med adgang til kildekode, dokumentation og konti kan en anden leverandør overtage, oftest efter en kodegennemgang. Det bureau der byggede produktet, har dog et videnforspring de første år, så et skifte bør begrundes med mere end en lille prisforskel.