Hur fattar du beslut om att bygga kontra köpa i organisatorisk skala?

Question

Accepted Answer

Huvudprincipen är enkel: **bygg det som skiljer dig åt, köp allt annat.** I organisatorisk skala handlar beslutet mindre om ett enda verktyg och mer om var du väljer att spendera din knappa ingenjörskapacitet.

## En beslutsram

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

Väga **total cost of ownership**, inte bara licenspris: integration, underhåll, anställning och möjlighetskostnad för de ingenjörer som inte arbetar på din produkt.

## Konkret exempel

Ett företag bygger sin rekommendationsfunktion (hjärtat i sin produkt) men köper sitt CRM, betalningshantering och loggningstack. Att bygga dessa skulle bränna ingenjörer på icke-differentierade arbete.

## Kompromisser och fallgropar

- **Fallgrop:** "not invented here"-syndrom, återuppbyggnad av varor för ego eller nöje.
- **Fallgrop:** köp för en kärnfunktion och oförmåga att differentiera.
- Köp skapar leverantörberoende; bygge skapar underhållsskuld. Välj din skuld medvetet.

## Varför det är viktigt

Ingenjörskapacitet är den mest begränsade resursen i de flesta företag.

Att spendera den på varor istället för differentierade funktioner är det vanligaste sättet på vilket bra team halkar efter.

Disiplinerad bygga-mot-köpa är hur en CTO styr den kapaciteten mot det som faktiskt vinner.