Byg det, der gør jeres produkt til noget særligt, og køb eller integrer resten. Det lyder enkelt, og det svære ligger i at være ærlig om, hvad der faktisk adskiller jer. Betaling, login, mailudsendelse og søgning er sjældent grunden til, at kunderne vælger jer, og de findes som færdige tjenester, som andre har brugt år på at gøre pålidelige. Bygger I dem selv, ejer I også vedligeholdet for altid. Køber I dem, får I en afhængighed, der skal vurderes. Valget handler derfor om, hvilken byrde I helst vil bære.
Tre muligheder
Byg selv. I skriver og ejer koden. Fuld kontrol, og I hæfter for fejl, sikkerhed og opdateringer i al fremtid.
Køb en tjeneste. En anden driver funktionen, og I tilkobler den via et API, en aftalt grænseflade mellem systemer. Hurtigt at komme i gang, og vilkår, pris og tilgængelighed ligger hos leverandøren.
Integrer en komponent. I bruger et færdigt bibliotek eller open source-værktøj, som I selv kører. I undgår at skrive det, og I står med drift og opdatering.
Det er nyttigt at holde de sidste to adskilt. Open source er ikke vedligeholdelsesfrit, og en købt tjeneste kræver også opfølgning.
De fem spørgsmål
Tag hver funktion for sig:
- Adskiller det os fra konkurrenterne? Ville en kunde vælge os på grund af netop det? Så er det kandidat til at bygge.
- Hvor modent er markedet? Findes der flere stabile tjenester, er det sjældent klogt at gå en anden vej.
- Hvad koster det at leve med? Tænk på vedligehold over årene, også sikkerhedsrettelser og nøglepersoner. Første version er den billige del.
- Hvor afhængige bliver vi? Hvad sker der, hvis leverandøren hæver prisen, ændrer vilkår eller lukker? Kan vi flytte?
- Hvor følsomme data går igennem? Hvad må tjenesten se, og hvor ligger det?
De klassiske eksempler
Betaling. Køb. Betalingskort, sikkerhedskrav, svindel og tilbageførsler er en branche i sig selv. Byg kun den del, der er specifik for jeres forretning, som reglerne for abonnementer og rabatter, og lad tjenesten stå for selve betalingen.
Login. Køb eller brug en etableret løsning. Adgangskoder, totrinslogin, nulstilling og senere krav fra store kunder om, at deres medarbejdere logger ind gennem kundens eget system, er arbejde uden ende. Se kravene fra den store kunde. Rettigheder inde i produktet, hvem der må hvad, skal I derimod selv forstå og styre, fordi det er tæt på forretningen.
Søgning. Start med det, databasen kan. Bliver søgning en kerne i produktet, kan en særskilt tjeneste eller en selvstændig komponent komme på tale.
Notifikationer og mail. Køb afsendelsen, for det er svært at komme igennem til indbakken. Reglerne for, hvem der får hvad og hvornår, er jeres.
AI-funktioner. De fleste bør bruge en færdig sprogmodel hos en udbyder og bygge det, der ligger omkring den. Valget er uddybet i AI-funktioner i produktet.
Det, I skal se på ved en købt tjeneste
Køb bør ikke være en beslutning, der træffes af en udvikler med et kreditkort. Tjek:
- Hvor ligger data, og hvem er underleverandører?
- Hvad er tjenestens oppetid, og hvad gør vi, når den er nede?
- Kan vi få data ud igen, og hvordan?
- Hvordan ændrer vilkår og pris sig, når vi vokser?
- Er der mere end én person hos os, der forstår integrationen?
Læg et tyndt lag kode mellem produktet og tjenesten, så resten af koden ikke kender leverandørens navn. Det gør et senere skifte til en afgrænset opgave. Hold også en liste over tjenesterne, så salget kan svare på kundernes spørgsmål, og så I ikke opdager en afhængighed under et nedbrud.
Reglerne spiller også ind. Efter Cyber Resilience Act, EU’s forordning om cyberrobusthed, er det Kommissionens opfattelse, at en tredjeparts færdige SaaS, der indgår i et produkt omfattet af forordningen, behandles som en komponent, hvor risici ved integrationen skal vurderes og håndteres. Vejledningen er ikke bindende. Fabrikanter skal også udvise omhu ved valg af komponenter, herunder fri software, se tredjepartsbiblioteker og SBOM. Open source har desuden licensvilkår, der kan binde jer, som beskrevet i open source-licenser i produktet.
Sådan bliver det til en beslutning
Lav en kort oversigt over produktets store funktioner, og sæt hver i en af tre kolonner: vores kerne, standard, der kan købes, og tvivl. Tvivlerne kræver en lille undersøgelse. Skriv begrundelsen ned, se skriv de tekniske beslutninger ned, så diskussionen ikke starter forfra, hver gang en ny udvikler kommer til.
Vær særligt opmærksom på to fristelser. Udviklere vil gerne bygge det, de finder interessant, og det er en sund drivkraft, der skal rettes mod det rigtige sted. Og AI-værktøjer gør det lettere at skrive en funktion selv, men vedligeholdet er det samme, når først funktionen ligger der. At noget hurtigt kan skrives, er ingen grund til at eje det.
Har I ingen, der kan afveje det, er netop den slags teknologivalg en opgave for en fractional CTO, og hos Nielco IT er rådgivningen uvildig, uden forhandleraftaler med de tjenester, der vurderes.
Valget skal tages op igen med jævne mellemrum. Det, der var rigtigt at bygge for år tilbage, kan i dag findes som en bedre tjeneste, og det, I købte, kan være blevet kernen.
Det skal I lade være med
· At bygge egen login eller betaling for at spare en månedlig regning. Vedligeholdet bliver større.
· At lade hver udvikler vælge sine egne tjenester. Hold et samlet overblik.
· At binde hele koden direkte til én leverandør. Læg et lag imellem.
· At regne open source som omkostningsfrit. Opdatering og drift er jeres.
Det skal I kræve af den eksterne
- ☐ En oversigt over produktets dele fordelt på bygge, købe og integrere.
- ☐ Anbefalinger uden økonomisk interesse i de valgte tjenester.
- ☐ Et overblik over afhængigheder, og hvad et skifte vil kræve.
- ☐ En vurdering af vedligeholdet over årene.
Kilder
- Europa-Kommissionen: vejledning om Cyber Resilience Act, C(2026) 5252: nr. 200 til 202 om tredjeparts SaaS. Ikke bindende.
- Kommissionens FAQ om Cyber Resilience Act: afsnit 4.4 om komponenter.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Teknologivalg til MVP’en · Cloud og hosting til et SaaS-produkt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
