Kontrakt med en freelance udvikler: 14 punkter den skal indeholde

En god kontrakt med en freelance udvikler dækker 14 punkter, fra omfang og pris til ophavsret, persondata, ansvar og opsigelse. Mangler et af dem, er det typisk dér uenigheden opstår når projektet bliver presset.

Jeg er udvikler, ikke jurist, så brug listen som en praktisk tjekliste og ikke som juridisk rådgivning.

Den korte version: tjeklisten

Mange freelancere har standardvilkår. Bed om dem tidligt, og brug listen til at se hvad der mangler. Leder du stadig efter den rigtige person, så start med min guide til at hyre en udvikler.

Projektet: hvem, hvad og hvornår

1. Parter og kontaktpersoner

Angiv de juridiske parter med CVR-nummer, ikke kun navne. Skriv også hvem der er kontaktperson på hver side, og hvem hos dig der må godkende leverancer og ændringer. Uden en navngiven beslutningstager ender udvikleren med at vente, eller med at bygge efter den der sidst skrev en mail.

2. Omfang og leverancer

Beskriv leverancen konkret: funktioner, integrationer og hvilke enheder og browsere løsningen skal virke på. Skriv lige så tydeligt hvad der ikke er med, fx design, tekster, hosting eller support efter lancering. Læg gerne projektbeskrivelsen ved som bilag, så selve kontrakten ikke bliver 30 sider.

3. Ændringer undervejs

Nye ønsker undervejs er normale. Kontrakten skal bare sige hvordan de håndteres: du beskriver ændringen, udvikleren giver et skriftligt estimat på pris og tid, og arbejdet starter først når du har godkendt det. Så får du aldrig en regning for timer du ikke har sagt ja til.

4. Tidsplan og milepæle

Aftal milepæle frem for kun en slutdato, og knyt dem gerne til betalingen. Skriv også hvad du selv skal levere: tekster, adgange og feedback inden for et bestemt antal dage. Tidsplanen bør rykke tilsvarende hvis dine leverancer kommer for sent.

Pengene: pris, betaling og accept

5. Pris og prismodel

Skriv prismodellen ud: fast pris for et afgrænset omfang, timepris med et månedligt loft eller en kombination. Angiv om beløbene er ekskl. moms, hvad der er inkluderet (møder, test, projektledelse), og hvordan licenser og hosting afregnes. Ved timepris bør du få en timeopgørelse med hver faktura.

6. Betaling

En almindelig model er rater knyttet til milepæle: en del ved opstart, en del undervejs og resten ved accept. Skriv både betalingsfristen og konsekvensen af forsinket betaling ind. Som køber er det rimeligt at holde en mindre del tilbage til accept. Som freelancer er det lige så rimeligt at sætte arbejdet på pause ved ubetalte fakturaer.

7. Test, accept og fejlretning

Definér hvornår en leverance er godkendt: hvem der tester, hvor lang tid du har (fx 10 arbejdsdage), og hvad der tæller som en fejl frem for et nyt ønske. Aftal også en periode efter accept hvor udvikleren retter fejl uden beregning. Drift og opdateringer derefter hører hjemme i en serviceaftale med din udvikler, ikke i projektkontrakten.

Rettighederne: kode, open source og adgange

8. Ophavsret til koden

Skriver en ansat et program som led i sit arbejde, overgår ophavsretten til arbejdsgiveren efter ophavsretslovens § 59. Den regel gælder ikke for en freelancer. Kontrakten skal derfor overdrage rettighederne til dig, og gerne bredt: efter § 53, stk. 3 får du nemlig ikke automatisk ret til andre former for brug end dem der er aftalt. Aftal også hvornår overdragelsen sker, fx ved betaling.

Mange freelancere genbruger generelle byggeklodser på tværs af kunder. Det er helt i orden, men så skal du have en tidsubegrænset brugsret til de dele. Jeg har skrevet mere om hvem der ejer koden, og hvilke adgange du skal sikre dig.

9. Open source og tredjepartskomponenter

Rettighederne til open source-pakker (frit tilgængelig kode) og betalte tjenester kan udvikleren ikke overdrage, så kontrakten bør sige at de bruges på deres egne licensvilkår. Bed om en liste over væsentlige komponenter og betalte licenser, og aftal at licenser som kan kræve at din egen kode frigives (fx GPL og AGPL), kun bruges hvis du har godkendt det.

10. Adgange, repository og hosting

Koden bør ligge i et repository på din egen konto hos fx GitHub eller GitLab. Domæne, hosting og tredjepartskonti bør stå i dit navn med udvikleren som bruger. Så kan du give og fjerne adgang uden at spørge nogen. Skriv at alle adgange og nøgler overdrages ved afslutningen og aldrig må tilbageholdes som pres i en uenighed.

Risikoen: fortrolighed, persondata og ansvar

11. Fortrolighed

Udvikleren får indsigt i din forretning og ofte dine data. En fortrolighedsklausul i kontrakten er som regel nok: hvad der er fortroligt, hvad der ikke er, og at pligten gælder efter samarbejdet slutter. Aftal også om udvikleren må vise projektet i sin portfolio. Om du har brug for en separat aftale før de første samtaler, gennemgår jeg i artiklen om hvornår en NDA med en udvikler er fornuftig.

12. Persondata og databehandleraftale

Får udvikleren adgang til oplysninger om dine kunder eller medarbejdere, er udvikleren typisk databehandler for dig. Så skal I have en skriftlig databehandleraftale efter artikel 28 i GDPR, og det er dit ansvar som dataansvarlig at den bliver lavet. Datatilsynets side om dataansvarlige og databehandlere har en skabelon du kan tage udgangspunkt i. Kan udvikleren arbejde med testdata i stedet for rigtige persondata, er det endnu bedre.

13. Ansvar og ansvarsbegrænsning

Det er almindeligt at en freelancekontrakt begrænser udviklerens ansvar, ofte til det beløb der er betalt for opgaven, og udelukker indirekte tab som driftstab og tabt fortjeneste. Det er rimeligt: ingen freelancer kan bære risikoen for hele din omsætning. Tjek at begrænsningen ikke gælder ved grov uagtsomhed eller forsæt, og spørg om udvikleren har en professionel ansvarsforsikring. En almindelig erhvervsansvarsforsikring dækker typisk ikke rene økonomiske tab.

Når samarbejdet slutter

14. Opsigelse, overdragelse og tvister

Aftal hvordan begge parter kan opsige aftalen, med hvilket varsel, og hvad der sker med betalingen. Typisk betaler du for det udførte arbejde frem til opsigelsen. Det vigtigste er overdragelsen: kode, dokumentation, adgange og en kort gennemgang til den næste udvikler. Skriv også hvilket lands ret der gælder, og hvor en tvist skal afgøres. Står du allerede midt i et skifte, har jeg skrevet om hvordan du skifter udvikler midt i et projekt uden at miste alt.

Næste skridt

Brug tjeklisten når du får et tilbud. Sæt flueben ved hvert punkt tilbuddet eller vilkårene dækker, og spørg ind til resten før du skriver under. De punkter der mangler, kan du tage op sammen med de spørgsmål du bør stille en udvikler før du hyrer. Er beløbet stort, eller er der persondata og forretningskritiske systemer involveret, så få en advokat til at læse aftalen igennem.

Jeg starter selv større opgaver med et betalt forprojekt til fast pris, og koden er din fra første dag. Se mine ydelser og hvordan et samarbejde foregår.

Ofte stillede spørgsmål

Kan jeg bruge en kontraktskabelon fra nettet?+

Ja, en skabelon er et fint udgangspunkt, men den skal tilpasses. Generiske skabeloner mangler ofte netop det der er særligt for software: overdragelse af ophavsret, open source-licenser, adgange og databehandling. Sammenlign skabelonen med tjeklisten, og stryg det der ikke passer. En skabelon til et konsulentforløb på timer passer sjældent til et projekt på fast pris.

Er et accepteret tilbud nok som kontrakt?+

Til mindre opgaver på 10-20 timer er det ofte nok. I Danmark er aftaler som udgangspunkt bindende uanset form, så et tilbud du accepterer på mail, er også en aftale. Problemet er bevis: det der ikke står skrevet, er svært at håndhæve. Lad tilbuddet henvise til udviklerens vilkår. En databehandleraftale skal dog altid være skriftlig.

Skal kontrakten nævne AI-værktøjer?+

Ja, det er en god idé fordi mange udviklere i dag skriver kode med hjælp fra AI-assistenter. Aftal om det er tilladt, og at din kode og dine data ikke må deles med tjenester der kan træne på dem. Udvikleren bør stå inde for al leveret kode uanset hvordan den er skrevet.

Hvem skal skrive kontrakten, mig eller udvikleren?+

Ofte sender udvikleren et tilbud med sine standardvilkår, og så tilpasser I dem sammen. Det er hurtigere end at starte fra bunden. Har din virksomhed egne indkøbsvilkår, kan du bruge dem i stedet, men tjek at de passer til softwareudvikling. Vilkår skrevet til køb af varer siger sjældent noget om kildekode, licenser og accepttest.