Hvordan tar du build-vs-buy-avgjørelser i organisatorisk skala?

Question

Accepted Answer

Kjernestrammet er enkelt: **bygg hva som differensierer deg, kjøp alt annet.** I organisatorisk skala handler avgjørelsen mindre om et enkelt verktøy og mer om hvor du velger å bruke din knappe ingeniørkapasitet.

## 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
```

Vei **total kostnad for eierskap**, ikke bare lisenskostnad: integrasjon, vedlikehold, ansettelse og multighetskostnad for ingeniørene som ikke jobber med produktet ditt.

## Konkret eksempel

Et selskap bygger sin anbefalingsmotor (hjerte av produktet sitt), men kjøper sin CRM, betalingsbehandling og logging stack. Å bygge disse ville brenne ingeniører på ikke-differensierende arbeid.

## Avveiinger og fallgruver

- **Fallgruv:** "ikke oppfunnet her"-syndrom, som bygger opp varer igjen for ego eller moro.
- **Fallgruv:** kjøper for en kjernefunksjon og er ikke i stand til å differensiere.
- Kjøp skaper leverandøravhengighet; bygging skaper vedlikeholdsgjeld. Velg gjelden din med vilje.

## Hvorfor det er viktig

Ingeniørkapasitet er den knappeste ressursen i de fleste bedrifter.

Å bruke det på varer i stedet for differensierer er den vanligste måten gode lag faller bak på.

Disziplinert build-vs-buy er hvordan en CTO dirigerer den kapasiteten mot det som faktisk vinner.