Hogyan hozz build-versus-buy döntéseket szervezeti szinten?

Question

Accepted Answer

Az alapelv egyszerű: **azt építsd meg, ami megkülönböztet, mindent mást vásárolj meg.** Szervezeti szinten a döntés nem egyetlen eszközről szól, hanem arról, hogy hol költsz el korlátozott mérnöki kapacitásodat.

## Döntési keretrendszer

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

Súlyozd a **teljes tulajdonlási költséget**, ne csak a licencdíjat: integráció, karbantartás, felvétel és a mérnökök lehetőségköltségét, akik nem a terméken dolgoznak.

## Konkrét példa

Egy cég felépíti ajánlómotor-rendszerét (terméke szíve), de megvásárol CRM-et, fizetési feldolgozást és naplózási stacket. Ezeket megépíteni a mérnököket nem-differenciáló munkára pazarolná.

## Kompromisszumok és csapda

- **Csapda:** "nem itt találták fel" szindróma, árucikkek újraépítése az ego vagy szórakozás miatt.
- **Csapda:** vásárlás alapvető képességhez és differenciálhatóság hiánya.
- A vásárlás szállítói függőséget hoz létre; az építkezés karbantartási adósságot hoz létre. Tudatosan válassz adósságot.

## Miért fontos

A mérnöki kapacitás a legtöbb cégnél a legritkább erőforrás.

Annak eltöltése árucikkek helyett differenciátor funkciók helyett a leggyakoribb módja annak, hogy jó csapatok elmaradjanak.

A fegyelmezett build-versus-buy az, ahogy a CTO az azt a kapacitást olyan irányba tereli, ami valóban nyer.