Et produkt er først jeres i praksis, når I kan nå det uden at spørge nogen om lov. Det kræver, at fem ting står i virksomhedens navn med jeres egne administratorer: kodelageret, cloudkontoen, domænet, kontiene i app-butikkerne og de nøgler, der binder det hele sammen. Mange stiftere opdager først ved et leverandørskift, at udvikleren oprettede det hele på sit eget firma eller sin private mail. Tjekket tager få dage, og det er lettest at rette, mens samarbejdet kører godt.
At eje noget og at kunne nå det
Her er to forskellige spørgsmål. Rettighederne til koden afgøres af aftalen og ophavsretten, og de er gennemgået i hvem ejer koden. Tekniske konti er noget andet: hvem der står som ejer af den konto, hvor produktet faktisk ligger, og hvem der kan lukke den.
De to ting kan pege i hver sin retning. I kan have en stærk aftale om rettighederne og alligevel stå uden adgang en mandag morgen, fordi kontoen tilhører en person, der ikke svarer. Rettighederne vurderer en advokat. Kontiene kan I selv gå igennem.
De fem steder, I skal se efter
Kodelageret. Det engelske ord er repository: stedet, hvor koden ligger sammen med hele historikken over ændringer. Spørg, hvilken organisation der står som ejer på kodeplatformen, og om en person hos jer har ejerrollen. Bed om at se det selv, med jeres egen bruger.
Cloudkontoen. Her kører produktet og ligger databasen. Se, hvem kontoen er registreret på, hvem fakturaen går til, og hvilken mail der kan nulstille adgangen. Betaler I gennem leverandørens samlefaktura, står kontoen ofte i leverandørens navn.
Domænet og mailen. Domænet er produktets adresse, og tit hænger login og systemmails på det. Slå op, hvem domænet er registreret på, og hvem der kan ændre dets opsætning. Ved .dk-domæner kan I spørge DK Hostmaster, hvem registranten er. Se samtidig, hvor domænet fornyes, og hvem der får påmindelsen.
App-butikkerne. Har I en mobilapp, ligger den under en udviklerkonto. Ligger den på bureauets konto, står bureauet som afsender over for brugerne, og flytningen skal gøres ordentligt, så bedømmelser og opdateringer følger med. Spørg tidligt, for det er ofte det led, der tager længst tid.
Nøgler og betalte tjenester. Produktet taler med betaling, mail, kort og AI-tjenester gennem nøgler, en slags adgangskoder for maskiner. Bed om en liste over alle tjenester, og hvilken konto hver af dem hører til. De små tjenester er nemme at glemme, og de stopper produktet lige så effektivt som de store. Mere om, hvordan nøglerne bør opbevares, står i nøgler og adgangskoder i koden.
Sådan laver I gennemgangen
Lav et ark med en linje pr. konto og fire kolonner: hvad det er, hvem der står som ejer, hvem der har administratoradgang, og hvor mailen til nulstilling går hen. Ark af den slags tager en udvikler kort tid at udfylde, når det bliver bedt om. Selve kontrollen foregår ved, at en person hos jer logger ind og ser det med egne øjne.
Princippet for administratorer er det samme, som ekstern-it-chef.dk beskriver for almindelige virksomheder: få og navngivne personer, personlige konti og ingen delte logins. I en softwarevirksomhed skal I lægge særlig vægt på den fælles postkasse. Brug en adresse som drift@ på jeres eget domæne som ejer af konti, så de ikke forsvinder, når en person stopper.
Spørg også efter den nødadgang, I selv kan bruge: adgangskoder og koder til tofaktorlogin, altså det ekstra trin ud over adgangskoden, opbevaret i en adgangsboks, som to personer i ledelsen kan åbne. Står stifteren alene med mobilen, har I en ny udgave af det samme problem.
Når noget står forkert
De fleste tilfælde skyldes bekvemmelighed. Bureauet oprettede kontoen, fordi det gik hurtigst, og ingen spurgte. Tag det derfor som en praktisk opgave: “Vi er ved at samle produktets konti hos os selv, så vi kan bestå en kundes spørgsmål og have orden. Hvornår kan vi lave overførslen?”
Rækkefølgen er vigtig. Flyt først det, der er nemt og ufarligt, så kodelager og domæne. Cloudkontoen kræver mere planlægning, fordi en flytning kan betyde nedetid, og den skal aftales med dem, der driver produktet. Lad udvikleren eller bureauet beholde den adgang, de skal bruge for at arbejde. Målet er, at I står som ejer, og at de er gæster.
Bliver svaret undvigende, er det i sig selv en oplysning. Tag det op skriftligt, og se leverandøren vil ikke udlevere koden, hvis det går i hårdknude. For nye aftaler hører kravet hjemme i de tekniske krav i udviklingsaftalen, så kontiene oprettes rigtigt fra første dag.
Næste skridt er enkelt: lav arket denne uge, og få det udfyldt af den, der bygger for jer. Svaret fortæller jer, om I kan tage over på en dag eller først skal i forhandling.
Det skal I lade være med
- At tage en mundtlig forsikring for gode varer · bed om at se ejerrollen med jeres egen bruger.
- At lægge alt på stifterens private mail · så flytter risikoen bare fra bureauet til én person hos jer.
- At flytte cloudkontoen uden en plan · en hastig flytning kan tage produktet ned.
- At vente, til samarbejdet er dårligt · overførsler er lette at aftale, mens stemningen er god.
Det skal I kræve af den eksterne
- ☐ En liste over alle konti, der bærer produktet, med ejer og administratorer.
- ☐ Kontrol med jeres egne logins frem for skærmbilleder.
- ☐ En plan for at flytte det, der står forkert, med rækkefølge og datoer.
- ☐ Nødadgang, som mindst to personer i ledelsen kan bruge.
- ☐ Tydelig grænse mod det, advokaten skal vurdere.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Freelancer, bureau eller eget team til første version · Første version er leveret: hvad nu?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
