Serviceaftale med en udvikler: hvad skal den dække?
Serviceaftale med en udvikler: tjekliste over svartider, opdateringer, backup, timer og opsigelse, så du ved præcis hvad du betaler for hver måned.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 8 min.
Indhold i indlægget8
En serviceaftale med en udvikler skal som minimum dække fem ting: hvor hurtigt der bliver reageret når noget går galt, hvilke opdateringer der laves og hvor tit, hvordan backup og overvågning er sat op, hvor mange timer der er inkluderet, og hvad der sker den dag aftalen stopper. Står de fem ting ikke på skrift, har du reelt kun et telefonnummer og en god vilje.
Jeg tilbyder selv vedligehold, så læs med det i baghovedet, men tjeklisten virker uanset hvem du skriver under med.
Den korte version: tilpas aftalen til hvor kritisk systemet er
Der findes ikke én rigtig serviceaftale. Niveauet skal passe til hvad det koster dig når systemet står stille. Min tommelfingerregel ser sådan ud:
| Hjemmeside eller internt værktøj | Webapp som kunder bruger dagligt | Forretningskritisk døgnet rundt | |
|---|---|---|---|
| Reaktion på kritisk fejl | Inden for 1 hverdag | Inden for få timer i arbejdstiden | Minutter, også om natten |
| Opdateringer | Fast månedlig runde | Sikkerhedsrettelser løbende plus månedlig runde | Løbende, med testmiljø og fast udgivelsesproces |
| Backup | Dagligt | Dagligt eller oftere, gendannelse testet | Flere gange dagligt, dokumenteret gendannelsestid |
| Overvågning | Oppetid | Oppetid og fejllogning | Oppetid, fejllogning og vagtordning |
| Typisk leverandør | Freelancer | Freelancer med stedfortræder | Bureau eller internt team |
Den sidste kolonne kan en enkelt freelancer ikke love troværdigt. Mere om det længere nede.
Serviceaftalen er den skriftlige ramme om drift og vedligehold. Vil du forstå selve arbejdet, så start med min guide til drift og vedligehold af webapps.
Tjeklisten: 13 punkter din serviceaftale skal dække
Brug listen når du læser et udkast eller et tilbud igennem. Mangler et punkt, så spørg ind til det før du skriver under.
Serviceaftale med en udvikler: 13 punkter
- Omfang: hvilke systemer, domæner, servere og integrationer aftalen dækker, og hvad der udtrykkeligt ikke er med.
- Fejlkategorier: en klar definition af kritisk, alvorlig, normal og ønske, så I er enige om hvad en kritisk fejl er, før den sker.
- Svartid og løsningstid: hvor hurtigt udvikleren reagerer, og hvornår fejlen senest er løst eller har en midlertidig løsning.
- Tidsrum: hvilke dage og timer svartiderne gælder, og hvad der sker med en fejl fredag aften.
- Kontaktkanal: hvor du melder fejl, og hvordan du markerer at noget er kritisk.
- Sikkerhedsopdateringer: hvor hurtigt kritiske rettelser til framework, PHP og pakker bliver lagt på, og at det er inkluderet.
- Versionsopgraderinger: om en ny hovedversion af fx Laravel er inkluderet, eller om den prissættes separat og planlægges i god tid.
- Backup: hvor tit, hvor længe den gemmes, hvor den ligger (helst et andet sted end serveren), og hvor tit gendannelse testes.
- Overvågning: hvad der overvåges (oppetid, fejl, udløb af SSL-certifikat og domæne), og hvem der får besked.
- Timer: antal inkluderede timer, hvad de må bruges på, om ubrugte timer kan overføres, og prisen på ekstra timer.
- Ferie og fravær: hvem der dækker når udvikleren er væk, og hvordan du får det at vide i forvejen.
- Adgange og ejerskab: koden ligger i dit repository (kodearkiv), hosting og domæne står i dit navn, og dokumentationen er opdateret.
- Opsigelse og overdragelse: varslet, og hvad udvikleren skal levere og hjælpe med når I stopper.
Har udvikleren adgang til persondata i systemet, er vedkommende typisk databehandler, og så skal I også have en databehandleraftale. Datatilsynet forklarer rollefordelingen mellem dataansvarlig og databehandler med eksempler. Det her er ikke juridisk rådgivning, så spørg en rådgiver hvis du er i tvivl.
Svartider: skeln mellem reaktion og løsning
En klassisk misforståelse er "svartid på 2 timer". Det betyder som regel at nogen bekræfter at de har set din henvendelse. Det betyder ikke at fejlen er løst.
En god aftale har derfor to tal for hver fejlkategori:
- Reaktionstid: hvornår udvikleren er i gang med at undersøge fejlen.
- Løsningstid: hvornår fejlen senest er rettet, eller der er en midlertidig løsning der holder forretningen kørende.
Løsningstiden kan sjældent garanteres når fejlen ligger hos andre, fx hosting, betalingsudbyder eller en ekstern API. Skriv det ind, så I ikke skal diskutere det midt i en driftsforstyrrelse.
Min egen faste regel er at svare på henvendelser inden for 1 hverdag. Det dækker de fleste ønsker og almindelige fejl. Skal kritiske fejl håndteres inden for timer, skal det stå i aftalen som et særskilt niveau, fordi udvikleren så skal planlægge sin dag efter det.
Spørg også ind til ferie. En freelancer er én person, og det er modellens største svaghed. Den ærlige løsning er en navngiven stedfortræder med adgang til dokumentationen, eller en skriftlig nødplan, fx en vejledning i hvordan hostingudbyderen gendanner seneste backup. Har udvikleren ikke et svar, har du fundet et hul i aftalen.
Opdateringer og backup: det usynlige arbejde skal stå på skrift
Det meste vedligehold kan du ikke se. Derfor er det også det der bliver sprunget over når der er travlt.
Framework- og PHP-versioner har en udløbsdato. Ifølge Laravels supportpolitik får hver hovedversion fejlrettelser i 18 måneder og sikkerhedsrettelser i 2 år. Laravel 11 holdt op med at få sikkerhedsrettelser 12. marts 2026, og PHP 8.2 får sikkerhedsopdateringer til 31. december 2026. Kører dit system på en version uden support, bliver nye sikkerhedshuller ikke lukket. Er dit system allerede langt bagud, kan du læse om tegnene på at et gammelt PHP-system skal moderniseres.
Aftalen skal derfor skelne mellem tre slags opdateringer:
- Sikkerhedsrettelser: lægges på hurtigt og er inkluderet.
- Løbende pakkeopdateringer: en fast runde, fx månedligt, også inkluderet.
- Hovedversioner: ofte et lille projekt, prissat for sig, men planlagt så du aldrig ender uden support.
Hvorfor det bliver dyrere at vente, har jeg skrevet om i indlægget om opdatering af framework og pakker.
Backup følger samme mønster. Mange hostingudbydere tager en form for backup, men det siger intet om hvorvidt en gendannelse virker. Min guide til backup af en webapp gennemgår strategien, og overvågning af din webapp dækker den anden halvdel: at du opdager fejlen før dine kunder gør.
Timer og pris: sådan undgår du overraskelser på fakturaen
Serviceaftaler afregnes typisk på en af tre måder:
- Fast månedligt beløb med inkluderede timer: forudsigeligt, og udvikleren kan reservere tid til dig. Til gengæld betaler du også i rolige måneder.
- Klippekort: du køber en pulje timer og bruger af dem. Fleksibelt, men giver sjældent en garanteret svartid.
- Ren timebetaling: ingen fast udgift, men heller ingen forpligtelse til at reagere hurtigt.
Forskellen på de to første har sit eget indlæg om retainer og klippekort. Uanset model skal tre ting stå klart: hvad de inkluderede timer må bruges på, hvad der sker med ubrugte timer, og hvordan du får besked før rammen er brugt op.
Min anbefaling er at lægge opdateringer, backup-tjek og overvågning i et fast beløb og lade ønsker og nye funktioner gå på timer. Så bliver det nødvendige ikke skubbet til side af det sjove.
Hvornår en freelancer ikke er det rigtige valg
Jeg vil hellere sige det her end at love noget jeg ikke kan holde:
- Du har brug for vagt døgnet rundt. Koster en times nedetid om natten dig mange penge, skal du have et team med vagtordning. Det kan én person ikke levere.
- Dine kunder kræver formelle garantier. Krav om dokumenterede processer, revision eller bod ved brud på svartider passer bedre til et bureau eller en driftsleverandør.
- Systemet er for simpelt til en aftale. En lille hjemmeside kan ofte klare sig med hosting der selv opdaterer, og en udvikler du kontakter efter behov.
Gælder ingen af de tre for dig, passer en freelancer med en klar aftale ofte godt. Du får direkte kontakt til den der kender koden, uden lag af projektledere imellem.
Næste skridt: fra tjekliste til underskrevet aftale
- Skriv ned hvad det koster dig hvis systemet er nede en time, en dag og en uge. Det afgør niveauet.
- Gå tjeklisten igennem og marker de punkter din nuværende aftale eller dit tilbud ikke dækker.
- Bed udvikleren svare skriftligt på de punkter der mangler.
- Tjek at kode, hosting og domæne står i dit navn før du skriver under.
Vil du se hvordan jeg selv griber det an, kan du læse om vedligehold og videreudvikling af eksisterende systemer. Mine priser står på prissiden.
Ofte stillede spørgsmål
Hvad koster en serviceaftale med en udvikler?
Det afhænger af hvor kritisk systemet er, og hvor mange timer der skal reserveres hver måned. Prisen bør kunne forklares ud fra to ting: antallet af inkluderede timer og den svartid du får. Reaktion inden for få timer koster mere end svar inden for 1 hverdag, fordi udvikleren skal holde tid fri. Bed om at få prisen delt op, så du kan se hvad du betaler for.
Er en serviceaftale det samme som en SLA?
Ikke helt. En SLA (service level agreement) beskriver serviceniveauet: svartider, oppetid og fejlkategorier. En serviceaftale er bredere og dækker også opdateringer, backup, timer, ejerskab og opsigelse. Ordene bliver ofte brugt om hinanden, så tjek indholdet frem for overskriften på dokumentet.
Kan jeg få en serviceaftale på et system en anden udvikler har bygget?
Ja, men regn med en opstartsfase. Den nye udvikler skal gennemgå kode, hosting og afhængigheder, før det er realistisk at love svartider. Gennemgangen afslører ofte forældede pakker eller manglende backup, som skal på plads først. Det er en engangsudgift, og den er billigere end at opdage hullerne under en kritisk fejl.
Hvor lang binding bør en serviceaftale have?
Der er ingen fast standard, men jeg anbefaler en løbende aftale med kort opsigelse, fx en til tre måneder, frem for et års binding før I har prøvet samarbejdet af. Tjek også at varslet gælder begge veje. Stopper udvikleren, skal du have tid nok til at finde en ny og få overdraget adgange og dokumentation.