Opdateret 18. oktober 2026
Den dag jeres udvikler stopper, finder I ud af, hvor god kontrakten var. Har I adgang til koden? Ved I, hvor den kører? Må I overhovedet lade en anden arbejde videre på den?
Jeg har arbejdet med softwareudvikling i mere end 30 år og har siddet på begge sider af bordet: som den, der leverer udviklingen, og som den, der køber den. Her er de punkter, jeg mener, hører med i en kontrakt med en freelanceudvikler eller et softwarehus. Ikke alle er lige vigtige for alle, men de første fire bør I aldrig springe over.
Jeg er ikke jurist. Brug listen som tjekliste, og lad en advokat se på den endelige kontrakt.
Punkt 1-4
De fire vigtigste
Ophavsret og brugsret til koden
Det er det punkt, flest overser. At I har betalt for koden, betyder ikke nødvendigvis, at I ejer den. Hvem der har rettighederne, afhænger af, hvad der er aftalt, og uden en klar aftale kan det blive et spørgsmål om fortolkning, den dag I vil skifte udvikler. Sørg derfor for, at det står skriftligt, hvem der ejer koden, og hvad I må bruge den til.
Skriv i kontrakten:
- at ophavsretten til den kode, der udvikles til jer, overdrages til jer, og hvornår (fx løbende eller ved betaling),
- at I må ændre, videreudvikle og lade andre arbejde videre på koden,
- hvad der gælder for udviklerens egne standardkomponenter, som også bruges hos andre kunder.
Adgang til kildekode, servere og konti
Ejerskab på papiret hjælper ikke, hvis I ikke kan komme til koden. Aftal, at:
- koden ligger i et repository, som I ejer (fx en GitHub- eller Azure DevOps-konto i firmaets navn),
- hosting, domæne, app store-konti og tredjepartstjenester er oprettet i jeres navn, eller at I har administratoradgang,
- adgangskoder og nøgler opbevares et sted, I selv har adgang til.
Overdragelse, når samarbejdet stopper
Beskriv, hvad udvikleren skal levere ved ophør: den seneste kode, dokumentation, oversigt over servere og tjenester og et par timers overlevering til den næste udvikler. Aftal også, hvad det koster, så der ikke skal forhandles, når I står i en presset situation.
Databehandleraftale
Får udvikleren adgang til persondata, fx i en database med kunder eller brugere, er udvikleren jeres databehandler. Det kræver en databehandleraftale efter GDPR artikel 28. Det gælder også ved fejlsøgning i en produktionsdatabase.
Punkt 5-12
Resten af kontrakten
Hvad skal laves?
Beskriv opgaven, så begge parter kan se, hvornår den er løst: formål, vigtigste funktioner, teknologier og hvad der ikke er med. Ved løbende samarbejde kan det være nok at beskrive, hvordan opgaver bestilles og prioriteres.
Pris og betaling
Timepris, fast pris eller en fast månedlig aftale? Aftal, hvordan timer registreres og rapporteres, hvornår der faktureres, og hvad der sker med timer, der ikke bliver brugt.
Tidsplan og svartider
Milepæle for et projekt eller svartider for drift. Skal udvikleren hjælpe, hvis systemet går ned en fredag aften? Så skal det stå der, og det koster typisk ekstra.
Kvalitet, test og dokumentation
Hvad forventer I ud over koden? Automatiske tests, dokumentation, kodegennemgang eller opdatering af en driftsvejledning? Det, der ikke står i kontrakten, bliver ofte ikke lavet.
Open source, tredjepartskomponenter og AI-værktøjer
Næsten al moderne software bruger open source-biblioteker. Det er helt normalt, men licensen skal passe til jeres brug. Aftal, at udvikleren holder styr på licenserne og spørger, før der bruges betalte komponenter eller tjenester.
Spørg også, om udvikleren bruger AI-værktøjer til at skrive kode. Det gør de fleste i dag, også vi. Det vigtige er, at et menneske gennemgår og står inde for koden, og at jeres data og forretningshemmeligheder ikke sendes til tjenester, I ikke har godkendt.
Fortrolighed
Kundedata, forretningsplaner og selve koden må ikke deles med andre. En fortrolighedsklausul eller en NDA er standard.
Ansvar og garanti
Hvad sker der, hvis der er fejl? Aftal en periode, hvor fejl rettes uden beregning, og om der er et loft over udviklerens ansvar. Et realistisk loft er bedre end et urealistisk ubegrænset ansvar, som en lille leverandør alligevel ikke kan dække.
Opsigelse, tvister og lovvalg
Opsigelsesvarsel for begge parter, dansk ret og hvordan uenigheder løses: først forhandling, derefter mediation, voldgift eller domstolene.
Ejerskab som standard
Sådan gør vi hos Sanocast
Hos os er det standard, ikke et tilvalg:
- I ejer koden, og den kan ligge i jeres eget repository.
- I har adgang til hosting, domæner og tjenester.
- I kan stoppe samarbejdet og tage det hele med til en anden leverandør.
Har I en løsning, hvor I er i tvivl om, hvem der ejer hvad, eller hvor udvikleren er forsvundet? Så starter vi med et platform-tjek, hvor vi gennemgår kode, adgange og dokumentation og fortæller jer, hvor I står.
Læs også: Tech-partner til jeres SaaS · Softwareudvikling for SMV’er: priser, forløb og forventninger · IT-leverandør: sådan vælger du den rette partner
Klar til at tage næste skridt?
Lad os få en uforpligtende snak
Book en samtale og få en foranalyse med overblik over hvordan vi kan hjælpe samt et overblik over muligheder og økonomi.
Eller ring direkte til Karsten på 70 18 01 18
