Hvad koster drift og vedligehold af en webapp om året? Priser i 3 størrelser

Drift og vedligehold af en webapp koster typisk 15.000-60.000 kr. om året for et lille internt værktøj, 45.000-180.000 kr. for en kundevendt webapp med login og betaling og fra ca. 125.000 kr. for en platform eller SaaS. Prisen på drift og vedligehold dækker hosting, opdateringer, overvågning, backup og de små ændringer der altid kommer, men ikke nye funktioner. Alle tal er mine grove skøn ekskl. moms, regnet ud fra typisk timeforbrug og normale timepriser for erfarne freelanceudviklere i Danmark.

Jeg tilbyder selv vedligehold og videreudvikling, så læs med det forbehold. Jeg skriver også hvornår du kan nøjes med mindre end tabellen siger.

Den korte version: årligt budget i tre størrelser

Timerne er regnet med 800-1.200 kr. i timen, som er det niveau LønRadar angiver for seniorfreelancere i IT i 2026. Hosting og værktøjer er groft omregnet fra udbydernes priser, som ofte står i dollar. Tabellen er et udgangspunkt for et budget, ikke en prisliste.

Sådan finder du din størrelse: Bruger kun dine egne medarbejdere løsningen, er den lille. Logger dine kunder ind og betaler, er den mellem. Har den flere typer brugere eller abonnementer, er den stor. Størrelserne følger de samme niveauer som min gennemgang af hvad det koster at bygge en webapp, så du kan lægge de to budgetter ved siden af hinanden. Vil du se driften i sammenhæng med alle de andre udgifter til software, så start med min prisguide til softwareudvikling.

Hvad pengene går til, post for post

Hver post svarer til et område i den daglige drift. Hvad arbejdet indeholder i praksis, og hvem der bør have ansvaret, står i guiden til drift og vedligehold af webapplikationer. Her handler det om hvad det koster.

Hosting og tjenester

Hosting er sjældent den største post, selvom det er den de fleste tænker på først. Den dækker server, database, domæne, certifikater, afsendelse af e-mails, fillager og plads til backup.

En typisk opsætning til en Laravel-app er en virtuel server hos en cloududbyder og et værktøj til at styre den. Laravel Forge koster 12-39 dollar om måneden afhængigt af plan, og selve serveren betaler du for hos udbyderen ved siden af. En mindre server koster typisk et par hundrede kroner om måneden eller mindre, og derfor kan et internt værktøj sagtens køre for under 500 kr. om måneden alt inklusive.

Prisen stiger når der kommer flere dele på: en separat database, køer til baggrundsjob, flere servere og et testmiljø (staging). Testmiljøet er en post mange glemmer. Det kan koste næsten det samme som produktionsmiljøet, men det er der nye versioner bliver afprøvet, før dine kunder ser dem.

Gebyrer til betalingsløsninger og forbrug af AI-tjenester har jeg holdt uden for tabellen. De afhænger af din omsætning og dit forbrug, ikke af vedligeholdet.

Opdateringer og sikkerhed

Målt i timer er det den største faste post. Laravel giver hver hovedversion fejlrettelser i 18 måneder og sikkerhedsrettelser i to år, og der kommer en ny hovedversion hvert år (Laravels supportpolitik). PHP og JavaScript-pakkerne har deres egne planer. Står appen stille, kører den efter cirka to år på versioner der ikke længere får sikkerhedsrettelser.

Timerne går til den faste runde: tjek pakkerne for kendte sårbarheder, opdatér, kør de automatiske tests, afprøv på testmiljøet og sæt i drift. For et internt værktøj kan det være en runde på 3-5 timer hvert kvartal. For en kundevendt webapp anbefaler jeg en månedlig runde, og en platform med mange integrationer kræver mere.

Jeg har regnet den årlige opgradering til en ny hovedversion med i timerne. Laravel skriver selv at de stræber efter at den kan klares på en dag eller mindre, og det holder for apps der er holdt opdateret og har tests. Er din app flere versioner bagud, er det et selvstændigt projekt. Se hvad en Laravel-opgradering koster, før du lægger budgettet.

Overvågning og backup

Værktøjerne er billige. Sentry har en gratis plan til én bruger, og Team-planen koster 26 dollar om måneden ved årlig betaling. Oh Dear, der holder øje med oppetid, certifikater og planlagte job, starter ved 17 dollar om måneden for to sites. Backup kan ofte klares med udbyderens eget lager for få kroner.

Det der koster, er tiden: at sætte alarmerne op så de går til den rigtige person, at reagere når de går, og at teste en gendannelse fra backup et par gange om året. En test tager typisk et par timer, og det er den eneste måde at vide at backuppen virker. På store løsninger kommer længere opbevaring af logs, en statusside og tid til hændelser oveni.

Småændringer og support

Det er den post der svinger mest. Den dækker fejl som brugerne finder, en tekst der skal rettes, en ny kolonne i en eksport og tilpasninger når en ekstern tjeneste ændrer sit API. Det er ikke videreudvikling, men det er heller aldrig nul.

Min tommelfingerregel for grænsen: Tager ændringen under en halv dag, og ændrer den ikke hvordan appen virker, er det en småændring. Ellers er det videreudvikling og skal have sit eget estimat. Jeg anbefaler at aftale en fast ramme på forhånd, fx 2-5 timer om måneden til en kundevendt webapp, og at udvikleren spørger før rammen overskrides.

Hvorfor procentreglen rammer skævt for små løsninger

En udbredt tommelfingerregel er at sætte 10-20 % af byggeprisen af om året til vedligehold, og lidt mere hvis småændringer skal med. Hosting kommer oveni. Reglen er god til at sætte en første ramme, men den rammer skævt i begge ender.

Tre regneeksempler, alle ekskl. hosting:

1. Internt værktøj til 100.000 kr. Reglen giver 10.000-20.000 kr. om året. Men en opdateringsrunde hvert kvartal, backup og et par rettelser koster næsten det samme, uanset om værktøjet kostede 100.000 eller 250.000 kr. Små løsninger lander derfor tit over reglen.
2. Kundeportal til 400.000 kr. Reglen giver 40.000-80.000 kr. Det ligger inden for intervallet i tabellen ovenfor.
3. Platform til 1,5 mio. kr. Reglen giver 150.000-300.000 kr. Det passer igen, men krav til hurtig responstid og en dyrere hosting kan trække beløbet op.

Pointen er at vedligehold har en bund. Selv den mindste webapp skal opdateres og have taget backup, og den tid bliver ikke mindre fordi løsningen var billig at bygge. Brug procenten til at tjekke om dit budget er realistisk, men regn posterne ud hver for sig, når du skal sammenligne tilbud.

Det der flytter prisen op eller ned

Inden for hver størrelse er det de samme ting der afgør om du lander i den lave eller den høje ende:

• Hvor langt bagud versionerne er. En app på understøttede versioner koster det tabellen siger. En app der er tre hovedversioner bagud, kræver først en oprydning, som er en engangsudgift ved siden af driften.
• Automatiske tests. Med gode tests kan en opdatering kontrolleres på minutter. Uden dem skal alt afprøves i hånden, og hver runde tager længere tid.
• Antal integrationer. Hver forbindelse til et økonomisystem, en betalingsløsning eller et andet API kan ændre sig uden varsel. Regn med ekstra timer pr. integration.
• Krav til responstid. Svar inden for én arbejdsdag er noget andet end en vagtordning døgnet rundt. Det sidste koster markant mere, uanset hvem du køber det hos.
• Persondata og betalinger. Følsomme data kræver mere omhyggelige opdateringer, adgangsstyring og dokumentation.
• Valg af hosting. Administreret hosting koster lidt mere om måneden, men fjerner timer til at holde styresystemet opdateret.

Sådan bliver vedligehold typisk afregnet

Det samlede beløb afhænger ikke kun af timerne, men også af hvordan du betaler for dem. Der er tre almindelige modeller:

• Fast månedligt beløb. Udvikleren står for opdateringer, overvågning og backup efter en aftalt plan. Du får en forudsigelig udgift, men betaler også i måneder hvor der ikke sker noget synligt.
• Timebank eller klippekort. Du køber timer på forhånd og bruger af dem. Du betaler kun for den tid der går, men nogen skal huske at bestille opdateringerne.
• Timer efter behov. Billigst på papiret. Risikoen er at opdateringerne ikke bliver lavet, fordi ingen har fået opgaven, og at regningen kommer samlet, når noget går galt.

Til de fleste kundevendte webapps anbefaler jeg en kombination: et fast beløb til opdateringer, overvågning og backup og en lille timeramme til småændringer. Hvordan de løbende modeller fungerer i praksis, og hvad du skal være opmærksom på med ubrugte timer, står i guiden til retainer og klippekort.

Akutte fejl uden for arbejdstid afregnes ofte med et tillæg, så spørg til det før du skriver under. Og lad helst hostingudbyderen fakturere dig direkte, så abonnementet står i dit firmas navn og ikke følger med udvikleren, hvis I stopper samarbejdet.

Hvornår du ikke skal betale for en fast aftale

Jeg lever blandt andet af vedligehold, men en fast aftale er ikke altid det rigtige køb:

• Din løsning kører på en hostet platform hvor udbyderen står for opdateringerne. Så er det meste af arbejdet allerede dækket af abonnementet.
• Appen skal lukkes inden for et halvt år. Sørg for backup og sikkerhedsrettelser efter behov, og brug pengene på det der skal afløse den.
• Du har egne udviklere. Så er vedligehold en del af deres arbejde. Giv bare opdateringerne en fast plads i planlægningen.
• Du har brug for døgnvagt. Jeg svarer inden for én arbejdsdag, og det passer til de fleste B2B-systemer. Skal nogen reagere inden for minutter om natten, skal du bruge en driftsleverandør med vagtordning eller dit eget team.

Overvej også regnestykket som helhed. Koster driften mere om året end løsningen sparer dig, er det værd at undersøge om et standardsystem kan gøre det samme.

Sådan lægger du dit eget driftsbudget

1. Find din størrelse i tabellen ud fra hvem der bruger løsningen.
2. Skriv de faste udgifter op. Gå sidste års fakturaer for hosting, domæner og værktøjer igennem. Måske finder du et abonnement som ingen længere kan huske.
3. Tjek tilstanden. Hvilken PHP- og framework-version kører appen på, og hvornår slutter supporten? Er den bagud, så lav en separat post til oprydningen.
4. Sæt en timeramme til opdateringer og en til småændringer, og hold dem adskilt fra videreudvikling.
5. Læg en buffer på 10-15 % til det uforudsete, fx en udbyder der lukker en gammel version af sit API.
6. Følg op én gang om året. Sammenlign budget og forbrug, og justér rammen.

Der er flere udgifter end drift som sjældent står i et tilbud. Dem har jeg samlet i en liste over skjulte omkostninger i softwareprojekter.

Næste skridt

Find din størrelse i tabellen, og tjek hvilken version din app kører på. Er den opdateret, kan du bruge tallene direkte i budgettet. Er den bagud, så få først et overblik over hvad oprydningen koster, og læg den løbende drift oven i.

Vil du have hjælp, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps. Du taler direkte med mig som udvikler, du ejer koden, og du får svar inden for én arbejdsdag.

Ofte stillede spørgsmål

Er hosting med i prisen på en vedligeholdsaftale?+

Det varierer, så spørg altid. Nogle udviklere samler hosting og vedligehold i ét månedligt beløb, andre lader dig betale hostingudbyderen direkte. Jeg anbefaler det sidste, fordi abonnementet så står i dit firmas navn, og du kan skifte udvikler uden at flytte serveren. Uanset model bør aftalen sige hvem der betaler for server, backup, domæne og værktøjer til overvågning.

Hvad sker der hvis jeg springer vedligehold over et år eller to?+

Du sparer pengene nu og betaler dem senere. Efter et par år uden opdateringer kører appen typisk på versioner uden sikkerhedsrettelser, og næste opdatering bliver et projekt i stedet for en rutineopgave. Flere hovedversioner skal tages på én gang, nogle pakker er måske opgivet, og uden løbende tests er det svært at vide hvad der går i stykker. Det koster som regel mere end de sparede år.

Bliver vedligehold billigere med AI-værktøjer?+

Lidt. AI-værktøjer kan hjælpe med at læse ændringslogs, foreslå rettelser og skrive tests, og det sparer tid på rutineopgaver. Men nogen skal stadig vurdere ændringerne, teste dem og stå inde for at appen virker bagefter, og den del udgør det meste af prisen. Forvent en mindre besparelse på timerne, ikke at budgettet halveres.

Hvad koster det at få en ny udvikler til at overtage vedligeholdet?+

Regn med en engangsudgift til en gennemgang, før det løbende arbejde starter. Den nye udvikler skal have adgang til kode, server og tjenester og bruge tid på at forstå appen, versionerne og risiciene. For en mellemstor webapp er det typisk fra en halv til et par dages arbejde, afhængigt af dokumentation og tests. Bed om gennemgangen til fast pris, så du kender beløbet på forhånd.