De fleste aftaler med et udviklingshus er grundige om pris, betaling og ansvar og tavse om det, stifteren får brug for den dag, samarbejdet skal ændres. Fem tekniske punkter gør forskellen: hvem der kommer ind i koden og miljøerne, hvad dokumentationen skal kunne, hvordan der testes, hvordan en overdragelse foregår, og hvordan ændringer godkendes. Dem kan I formulere selv, før advokaten læser aftalen igennem. Her får I punkterne i almindeligt sprog og de spørgsmål, leverandøren skal kunne svare på. Selve kontraktteksten og rettighederne er et spørgsmål til advokat.
Adgang til kode og miljøer
Koden skal ligge et sted, hvor I selv har adgang fra første dag. I praksis betyder det et kodearkiv, altså det system, hvor koden og hele dens historik gemmes, på en konto, virksomheden ejer. Leverandøren får adgang som gæst. Det samme gælder domænet, cloudkontoen og app-butikkerne samt tjenesterne til mail og betalinger.
Skriv tre ting ind i aftalen:
- Hvilke konti der står i virksomhedens navn, og hvem der er administrator.
- At al kode lægges i jeres kodearkiv løbende, hver gang der arbejdes på den. En samlet aflevering til sidst giver jer ingen indsigt undervejs.
- Hvilke miljøer der findes, fx et testmiljø og et produktionsmiljø, og at I kan komme ind på dem begge.
Listen over, hvad der bør stå i jeres eget navn, er gennemgået under ejerskab af kode og konti. Hvem der har rettighederne til koden, er et separat spørgsmål, og det er beskrevet i hvem ejer koden.
Dokumentation, som en anden kan bruge
“Koden dokumenteres” er en formulering, der kan betyde alt. Beskriv i stedet, hvad dokumentationen skal kunne. En prøve er enkel: en udvikler, der aldrig har set produktet, skal kunne få det op at køre på sin egen maskine og udgive en ny version ved hjælp af det skrevne. Bed også om en kort beskrivelse af arkitekturen, altså produktets dele og hvordan de hænger sammen, og om en oversigt over eksterne tjenester og de biblioteker, produktet bygger på.
Dokumentationen hører med til leverancen. Står den som særskilt punkt til sidst, er den det første, der ryger, når tiden løber ud.
Test og kvalitet
Aftalen behøver ingen tal for testdækning for at være brugbar. Testdækning er et mål for, hvor meget af koden der bliver kørt igennem af automatiske test, og et højt tal siger i sig selv intet om, hvorvidt testene er gode. Skriv hellere:
- at de vigtigste forløb i produktet, fx oprettelse, betaling og login, har automatiske test,
- at testene køres, hver gang koden ændres, og at resultatet kan ses af jer,
- at en ny version først godkendes i testmiljøet af jer,
- hvordan fejl fundet efter levering håndteres, og hvor længe leverandøren retter dem.
Hvad der gør en leverance færdig, fortjener sin egen aftalte definition. Den findes i hvornår er en leverance færdig?.
En enkel proces for ændringer
Scope creep er det engelske ord for, at opgaven langsomt vokser, uden at nogen har besluttet det. Det rammer begge parter. Stifteren får en regning, der ikke ligner aftalen, og leverandøren får en kunde, der mener, at ønsket var indeholdt.
Den enkle løsning er en ændringsseddel på få linjer: hvad ændres, hvad betyder det for tid og betaling, og hvem har sagt ja. Skriv ind i aftalen, at intet arbejde uden for det aftalte begynder uden en sådan godkendelse, og hvem hos jer der må give den. Beskriv også, hvad der sker med det, der fjernes fra planen, så en ændring kan gå begge veje.
Er opgaven så uafklaret, at ingen kan beskrive den fuldt ud, kan I aftale korte perioder med fast indhold og et stop efter hver. Så ligger risikoen i små bidder, og begge parter kan tage en ny beslutning undervejs.
Overdragelse, mens I er gode venner
Det bedste tidspunkt at aftale slutningen er før begyndelsen. Beskriv, hvad leverandøren skal gøre, hvis samarbejdet stopper, uanset årsag:
- aflevere kode, historik, adgangsnøgler og dokumentation inden for en aftalt frist,
- afholde et aftalt antal overdragelsesmøder med den, der tager over,
- afslutte igangværende arbejde eller aflevere det, som det står,
- give de adgange fra sig, der stadig ligger hos dem.
Aftal også, om overdragelsen er indeholdt, eller hvordan den afregnes. Står det uafklaret, opstår diskussionen på det tidspunkt, hvor I har mindst at forhandle med. Forløbet er beskrevet i skift af udviklingsleverandør uden at miste produktet.
Tænkt eksempel
En stifter får et tilbud på første version af en app. Aftaleudkastet fylder mange sider og handler om betaling og ansvarsbegrænsning. Stifteren tilføjer et bilag på én side med de fem punkter fra denne artikel og beder leverandøren svare ja, nej eller med forbehold ud for hvert punkt. Svarene viser mere om samarbejdet end præsentationen gjorde, og forbeholdene kan tages op, mens begge parter stadig gerne vil aftalen. Bilaget kan laves, inden tilbuddet indhentes; se forberedelsen af et tilbud.
Det skal I lade være med
- At lade leverandøren oprette alle konti for jer · det er hurtigt i dag og besværligt den dag, I skal have dem tilbage.
- At kræve tal for testdækning uden at vide, hvad de betyder · et tal kan rammes med svage test.
- At sende aftalen til advokaten uden de tekniske krav · advokaten kan ikke gætte, hvad produktet har brug for.
- At gemme overdragelsen til den dag, samarbejdet er dårligt · så har I mindst indflydelse.
Det skal I kræve af den eksterne
- ☐ Et teknisk bilag til aftalen i et sprog, I selv kan læse.
- ☐ En liste over konti og adgange med virksomheden som ejer.
- ☐ En prøve af dokumentationen, før leverancen godkendes.
- ☐ Et forslag til ændringsproces, der kan bruges i hverdagen.
- ☐ Klar besked om, hvor det tekniske stopper, og hvor advokaten tager over.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Second opinion på et tilbud fra et udviklingshus · Leverandøren vil ikke udlevere koden
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
