Hvordan træffer du build-versus-buy-beslutninger i organisationsskala?

Question

Accepted Answer

Kerneprinippet er simpelt: **byg det, der differentierer dig, køb alt andet.** I organisationsskala handler beslutningen mindre om et enkelt værktøj og mere om, hvor du vælger at bruge din knappe engineering-kapacitet.

## En beslutningsramme

```text
BUILD when:
- It is core to your competitive advantage
- No adequate solution exists, or yours must be materially better
- The capability must evolve constantly with your product

BUY when:
- It is a commodity (auth, payments, email, observability)
- A mature vendor solution exists and fits well enough
- Time-to-market matters more than control
```

Vej **samlede ejerskabsomkostninger**, ikke kun licenspris: integration, vedligeholdelse, ansættelse og alternativomkostninger for ingenører, der ikke arbejder på dit produkt.

## Konkret eksempel

En virksomhed bygger sin anbefalingsmotor (hjerte af dens produkt), men køber sin CRM, betalingsbehandling og logging stack. Bygning af disse ville brænde ingenører på ikke-differentierende arbejde.

## Afvejninger og faldgruber

- **Faldgrup:** "ikke opfundet her"-syndrom, genbygning af råvarer for ego eller sjov.
- **Faldgrup:** køb for en kernekapabilitet og at være ude af stand til at differentiere.
- Køb skaber leverandørafhængighed; bygning skaber vedligeholdelsesgæld. Vælg dine gæld med vilje.

## Hvorfor det betyder noget

Engineering-kapacitet er den sjældneste ressource i de fleste virksomheder.

At bruge den på råvarer i stedet for differentiatiorer er den mest almindelige måde, hvorpå gode teams falder bagud.

Disciplineret build-versus-buy er, hvordan en CTO dirigerer denne kapacitet mod det, der faktisk vinder.