Undgå vendor lock-in: 10 greb så du kan skifte udvikler

Vendor lock-in betyder at du reelt ikke kan skifte udvikler, bureau eller platform fordi det ville koste for meget, tage for lang tid eller kræve at systemet bygges om. Du undgår det med ti greb der alle handler om det samme: konti i dit navn, udbredt teknologi, dokumentation der virker, og en proces hvor en anden udvikler kan tage over uden at starte forfra.

Jeg er selv freelanceudvikler, så jeg har en interesse i emnet. Hos mig ejer kunden koden fra første dag, netop så det er nemt at skifte væk fra mig, og de samme greb bør du forvente af enhver udvikler.

Den korte version

Greb 1, 3 og 6 giver mest beskyttelse for færrest timer. Starter du et nyt samarbejde, så tag dem op i de første samtaler. Er du ikke nået så langt endnu, så start med min guide til at hyre en udvikler, der gennemgår forløbet fra behov til kontrakt.

Ejerskab og adgange: fundamentet

De to første greb er ikke tekniske. De afgør om du overhovedet kan skifte, uanset hvor god koden er.

1. Alle konti står i virksomhedens navn

Repository (kodearkiv), hosting, database, domæne, betaling, mail og AI-tjenester skal være oprettet af virksomheden og betalt med virksomhedens kort. Udvikleren bliver inviteret som bruger med de rettigheder opgaven kræver og kan fjernes igen uden at du skal spørge om lov. API-nøgler (de nøgler systemet bruger til at tale med andre tjenester) hører hjemme i en adgangskodemanager som virksomheden styrer.

Det lyder banalt, men det er et typisk sted lock-in begynder. En udvikler opretter en konto for at komme hurtigt i gang, og to år senere er det stadig den konto alt kører på. Hvordan du flytter konti og repositories, og hvad du skal være opmærksom på ved domæner, gennemgår jeg i guiden om ejerskab af kildekode og adgange.

2. Rettigheder og en exit i kontrakten

Kontrakten skal overdrage rettighederne til koden, inklusive retten til at ændre den og lade andre udviklere bygge videre. Den skal også beskrive hvordan samarbejdet slutter:

• et rimeligt opsigelsesvarsel, så du ikke står uden udvikler fra den ene dag til den anden
• en pligt for udvikleren til at hjælpe med overdragelsen, typisk til den almindelige timepris
• hvad der udleveres ved ophør: kode, dokumentation, adgange og data

En exit-klausul er ikke et tegn på mistillid. Den gør et skifte kedeligt i stedet for dramatisk, og en seriøs udvikler har ingen grund til at sige nej. Resten af punkterne finder du i tjeklisten til kontrakten med en freelance udvikler.

Teknologi: byg på noget mange kan arbejde i

Den tekniske lock-in er sværere at få øje på fordi den først koster noget den dag du vil skifte. Tre valg afgør det meste.

3. Vælg udbredt standardteknologi

Jo flere udviklere der arbejder i den teknologi dit system er bygget i, jo lettere er det at finde en ny. Et system i Laravel, Django, Ruby on Rails, .NET eller React/Next.js med en PostgreSQL- eller MySQL-database kan mange udviklere overtage. Et system i et hjemmelavet framework eller et sjældent sprog kan kun få.

Min test er enkel: kan du finde tre andre udviklere eller bureauer der arbejder i netop den teknologi? Kan du ikke det, så spørg hvorfor udvikleren har valgt den. Vær også skeptisk over for mange små, ukendte pakker. Holder en af dem op med at blive vedligeholdt, sidder du fast i en gammel version.

Jeg arbejder selv i Laravel og React/Next.js, og en af fordelene er netop at de er så udbredte at en kunde ikke er afhængig af mig for at finde en der kan arbejde videre.

4. Hold forretningslogikken i din egen kode

Forretningslogik er de regler der gør dit system til dit: hvordan priser beregnes, hvem der må se hvad, og hvad der sker når en ordre annulleres. Ligger reglerne i din egen kode, kan de flyttes. Ligger de spredt i en no-code-platform, i en udbyders særlige serverfunktioner eller i opsætningen af et betalt værktøj, flytter de ikke med.

Det betyder ikke at du skal undgå tredjepartstjenester. Betaling, mail, SMS og AI køber du næsten altid. Men en god udvikler pakker dem ind bag et lille lag i koden, så resten af systemet ikke ved hvilken udbyder der sidder bag. Skal du skifte mailudbyder eller AI-model, ændrer du ét sted i stedet for hundrede.

Laravel er et godt eksempel på princippet. Frameworkets filsystem bruger den samme kode til filer på serveren og i S3-kompatibel lagring, og et skifte mellem S3-kompatible udbydere er typisk et spørgsmål om nye adgangsoplysninger og en ny adresse i konfigurationen. Filerne skal stadig flyttes, men koden skal ikke skrives om.

5. Hosting der kan flyttes

Dit system bør kunne køre på en almindelig Linux-server eller i en standardcontainer (fx Docker) hos mere end én udbyder. Konfiguration som databaseadgang, nøgler og adresser hører hjemme i miljøvariabler og ikke i koden. Det er et af principperne i The Twelve-Factor App, der har en god test: kunne koden lægges offentligt frem i morgen uden at afsløre en eneste adgangskode?

Serverless-platforme og administrerede tjenester hos de store cloududbydere kan sagtens være det rigtige valg. Men jo flere udbyderspecifikke tjenester systemet bygger på, jo mere skal skrives om ved et skifte. Vælg dem bevidst, og skriv valget ned (se greb 8).

Viden: få det ud af udviklerens hoved

Selv med konti i orden og standardteknologi kan du være låst hvis alt det der ikke står i koden, kun findes i én persons hoved.

6. En README der får en ny udvikler i gang

README er filen øverst i repository der forklarer projektet. Den skal som minimum beskrive hvordan projektet sættes op på en ny computer, hvordan det sættes i drift, hvilke eksterne tjenester det bruger, og hvor nøglerne ligger.

Min tommelfingerregel er at en erfaren udvikler skal kunne have projektet kørende på sin egen computer i løbet af den første arbejdsdag uden at ringe til nogen. Det er også det første en ny udvikler skal have ved onboarding af en freelance udvikler. Hvad dokumentationen ellers bør indeholde, har jeg samlet i en tjekliste til dokumentation af et softwareprojekt.

7. Tests og automatisk udrulning

Automatiserede tests er kode der tjekker at systemet gør det det skal. For dig er de mere end kvalitetssikring: de er dokumentation der ikke kan blive forældet. En ny udvikler kan ændre noget og med det samme se om noget andet gik i stykker. Uden tests tør ingen røre ved koden, og så er du reelt låst til den der skrev den.

Det samme gælder udrulning, altså hvordan nye versioner kommer i drift. Den skal ske automatisk via en pipeline (CI/CD, en automatisk proces der tester og udgiver koden) som ligger i dit repository, fx med GitHub Actions. Den må ikke afhænge af udviklerens egen computer og kommandoer som kun udvikleren kender.

8. Beslutninger skrevet ned

Hvorfor blev netop den database valgt? Hvorfor bruger systemet to betalingsudbydere? Hvilke genveje blev taget for at nå lanceringen? Svarene er ofte det en ny udvikler savner mest fordi de afgør om noget mærkeligt i koden er en fejl eller et bevidst valg.

En kort beslutningslog i repository løser det. Hver beslutning får et par linjer: hvad blev besluttet, hvorfor, og hvad var alternativet. Det tager få minutter at skrive og sparer timer ved et skifte. Skriv også den kendte tekniske gæld ned, altså de steder hvor koden bevidst er lavet hurtigt frem for grundigt.

Samarbejdet: hold døren åben løbende

De sidste to greb sikrer at du faktisk kan komme ud, og de bør tages mens alt kører godt.

9. Data du selv kan hente ud

Dine data er ofte mere værd end koden. Sørg for at backups af databasen ligger på en konto du ejer, og at du selv kan hente en uden at spørge nogen. Bruger systemet eksterne platforme, så tjek at du kan eksportere data i et standardformat som CSV eller JSON, og at eksporten indeholder det hele, også historik og filer.

Prøv det en gang. Det er bedre at opdage at eksporten mangler noget nu end den dag du har brug for den.

10. Test overdragelsen før du har brug for den

Det eneste sikre bevis på at du ikke er låst, er at en anden udvikler faktisk har arbejdet i systemet. Lad en uafhængig udvikler lave en kodegennemgang eller en lille, afgrænset opgave en gang om året eller ved større milepæle. Giv adgangene, lad udvikleren følge README'en, og se hvor det går i stå.

Det koster nogle timer, men det er langt billigere end at opdage hullerne når din faste udvikler pludselig ikke er der. En god udvikler bliver ikke fornærmet. Det er de samme spørgsmål en køber eller investor vil stille hvis du en dag skal sælge virksomheden.

Sådan ser du om du allerede er låst

Svar ærligt på fem spørgsmål:

1. Kan du logge ind på repository, hosting og domæne med din egen bruger i dag?
2. Står det i kontrakten at du ejer koden og må lade andre bygge videre?
3. Kan du nævne tre andre udviklere eller bureauer der arbejder i den teknologi systemet er bygget i?
4. Findes der en opsætningsvejledning som en anden udvikler har prøvet at følge?
5. Kan du hente en komplet backup af dine data uden at spørge nogen?

Er svaret nej til et eller to af spørgsmålene, er du ikke nødvendigvis i problemer, men du har en opgave. Er svaret nej til tre eller flere, så tag fat på det mens samarbejdet med din nuværende udvikler fungerer. Det er langt nemmere at få adgange og dokumentation fra en udvikler der er glad for samarbejdet, end fra en du lige har opsagt. Er det allerede kørt fast, så følg min guide til at skifte udvikler midt i et projekt.

Når lidt lock-in er det rigtige valg

Al software binder dig til noget. Målet er at du kender prisen for at skifte og har valgt den bevidst.

• Til en webshop, et bookingsystem eller et regnskabsprogram er Shopify eller et færdigt SaaS-produkt ofte billigere end at få noget bygget selvom du er låst til platformen. Sørg bare for at du ejer domænet og kan få dine data ud.
• En administreret database eller en mailtjeneste giver en lille afhængighed, men sparer dig for drift. Det er som regel en god handel.
• Et internt værktøj med fem brugere behøver ikke samme mængde dokumentation og tests som dit kerneprodukt. Afvej indsatsen mod hvad det ville koste at bygge det om.

Det gælder også hvis du overvejer at hyre mig. Har du brug for en standardløsning, er det ofte bedre at købe den end at få mig eller en anden udvikler til at bygge den. Og er dit system bygget i fx Java eller .NET, er en udvikler der arbejder i netop den teknologi et bedre valg end mig til at overtage det.

Næste skridt

Brug tjeklisten til dit eksisterende system eller til de første samtaler med en ny udvikler.

Start med de punkter du ikke kan sætte flueben ved, og tag konti og kontrakt først. Har du et eksisterende system der skal gennemgås, ryddes op i eller gøres klar til en anden udvikler, kan du læse om hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende løsninger. Du ejer koden fra første dag, så du kan skifte væk fra mig når du vil.

Ofte stillede spørgsmål

Hvad er kildekodedeponering, og har jeg brug for det?+

Kildekodedeponering (escrow) betyder at en uafhængig tredjepart opbevarer en kopi af koden og udleverer den hvis leverandøren går konkurs eller stopper. Det er relevant når du licenserer software fra en leverandør og ikke selv ejer koden. Ligger koden allerede i dit eget repository, har du sjældent brug for det fordi du har koden hele tiden. En deponeret kopi er i øvrigt kun nyttig hvis den er opdateret og faktisk kan bygges.

Bliver projektet dyrere af at undgå lock-in?+

Lidt, men meget mindre end at rette op bagefter. Konti i dit navn og et udbredt framework koster stort set intet ekstra. En god README, tests og et lag omkring tredjepartstjenester koster nogle timer undervejs. Til gengæld er det typisk langt dyrere at tilføje dokumentation og tests til et system der allerede er i drift, eller at bygge dele om ved et skifte fordi de var bundet til én udbyder.

Er det et dårligt tegn hvis udvikleren selv hoster min løsning?+

Ikke nødvendigvis. Mange udviklere og bureauer tilbyder hosting og drift som en del af aftalen, og det kan være praktisk. Problemet opstår hvis du ikke har adgang, ikke kan hente en backup eller ikke kan flytte løsningen uden udviklerens hjælp. Bed om administratoradgang, backups du selv kan hente, og en skriftlig aftale om hvordan løsningen udleveres hvis samarbejdet stopper.

Kan jeg undgå lock-in med no-code eller AI-værktøjer?+

Kun delvist. Med en no-code-platform ligger både data og forretningslogik hos udbyderen, så du kan sjældent flytte løsningen uden at bygge den om. Nogle AI-værktøjer kan eksportere den genererede kode til dit eget repository, og det hjælper meget. Tjek hvad dit værktøj kan eksportere før du bygger noget forretningskritisk, og regn med at koden skal gennemgås før en udvikler kan bygge videre på den.