CTO as a Service

Freelancer, bureau eller eget team til første version

Tre rygsække og en cykelhjelm under et langbord i et delekontor med høje vinduer, mens en udvikler set bagfra arbejder for enden af bordet

Til en første version passer en freelancer, når opgaven er afgrænset, og I selv kan styre den. Et bureau passer, når I vil købe et samlet hold og har en person til at styre leverandøren. Et eget team passer, når produktet skal være kernen i mange år, og der er nogen til at lede det. Valget afhænger af, hvad hver løsning kræver af jer i styring, og hvad der sker med viden, når samarbejdet slutter.

Freelanceren

En dygtig freelancer kan komme hurtigt i gang, og I taler direkte med den, der bygger. Der er ingen projektleder imellem, og beslutninger kan træffes samme dag.

Svagheden er sårbarheden. Bliver personen syg, får en større opgave eller holder op med at svare, står arbejdet stille. Freelanceren kan sjældent selv dække alt, fra brugerflade til database og drift, og I må derfor selv holde sammen på helheden.

Det kræver af jer, at I beskriver opgaven tydeligt, godkender små leverancer ofte og selv ejer konti og kode. Hvad I gør, hvis det går galt, står i udvikleren er holdt op med at svare.

Bureauet

Et bureau eller udviklingshus giver jer et hold med projektleder, designer og flere udviklere. Sygdom og ferie dækkes af andre, og der er en virksomhed bag aftalen.

Til gengæld har bureauet sine egne interesser. Det tjener på, at opgaven er stor, og det vælger gerne den teknologi, der passer til dets folk. Holdet kan skifte undervejs, og den stærke person fra salgsmødet er ikke altid den, der arbejder på opgaven. Når I går videre, tager holdet forståelsen af produktet med sig, medmindre I har krævet dokumentation.

Det kræver af jer, at I stiller krav til leverancer, test og overdragelse og har en person, der ejer produktet på jeres side. Et udviklingshus kan ikke samtidig være uvildig rådgiver i egen sag, se risikoen, når samme hus både rådgiver og bygger.

Eget team

Et eget team samler viden i virksomheden. Udviklerne kender kunderne, tager ansvar over tid og lever selv med konsekvenserne af deres valg. Det er den stærkeste model, når produktet er forretningen.

Den er også den langsomste at starte og den tungeste at rette, hvis retningen ændrer sig. Ansættelser tager tid, og hvem skal lede udviklerne, når ingen i ledelsen er tekniske? Se ansættelse af de første udviklere.

Sådan står de tre over for hinanden

  • Start · Freelancer: Hurtig · Bureau: Efter aftale · Eget team: Langsom
  • Styring fra jer · Freelancer: Tæt og daglig · Bureau: Som bestiller · Eget team: Som leder
  • Sårbarhed · Freelancer: Én person · Bureau: Holdskifte, interesser · Eget team: Ansættelser, ledelse
  • Viden efter stop · Freelancer: Går med personen · Bureau: Går med holdet · Eget team: Bliver hos jer

Det sker med viden, når samarbejdet slutter

Uanset model bør I regne med, at samarbejdet slutter en dag. Det, der overlever, er det, der er skrevet ned og ligger hos jer. Stil derfor de samme krav til alle tre fra første uge:

  1. Koden ligger i jeres repository, altså det kodearkiv, I selv ejer.
  2. Der findes en kort beskrivelse af, hvordan produktet startes, opdateres og gendannes.
  3. Vigtige valg er skrevet ned med begrundelse.
  4. Konti og nøgler står i virksomhedens navn.
  5. Overdragelse til en anden er aftalt, før den bliver aktuel.

Det gælder også rettighederne. Ophavsretslovens § 59 om, at rettigheder overgår til arbejdsgiveren, nævner arbejdstagere. For freelancere og bureauer er der ingen tilsvarende regel, så rettighederne skal aftales. At en leverandør beholder dem uden aftale, er vores læsning, og svaret i jeres sag må I få hos en advokat. Læs mere i hvem ejer koden.

Sådan vælger I

Tre spørgsmål giver som regel svaret:

  • Hvor stor er usikkerheden om produktet? Er meget uafklaret, er en lille afgrænset opgave sundere end en stor kontrakt.
  • Hvem styrer på jeres side? Uden en person med tid og teknisk dømmekraft vil alle tre modeller skuffe. Her kan en ekstern leder være det, der får modellen til at virke, se sådan styrer I en udviklingsleverandør.
  • Hvad er planen efter første version? Skal produktet hjem på sigt, bør det stå i aftalen fra starten.

Mange ender med en blanding, fx et bureau til første version og to ansatte, der overtager gradvist. Blandingen virker, så længe overdragelsen er planlagt fra starten.

Det skal I lade være med

  • At vælge alene efter, hvem der kan starte i morgen · hastværk i starten er dyrt senere.
  • At købe hele produktet som én stor fast opgave · del det i små leverancer.
  • At overlade styringen til leverandøren selv · den, der bygger, kan ikke også godkende.

Det skal I kræve af den eksterne

  • ☐ En anbefaling af model uden provision eller binding til leverandører.
  • ☐ Hjælp til at læse tilbud og aftaleudkast fra et teknisk synspunkt.
  • ☐ En enkel styringsrutine, som I kan holde selv.
  • ☐ En plan for overdragelse, inden første linje kode er skrevet.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Læs også: Second opinion på et tilbud fra et udviklingshus · Nearshore og offshore udvikling

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Mangler I en CTO?

Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.