Come si prendono decisioni di build-vs-buy a livello organizzativo?

Question

Accepted Answer

Il principio fondamentale è semplice: **costruisci quello che ti differenzia, compra tutto il resto.** A livello organizzativo la decisione non riguarda un singolo strumento, ma piuttosto dove scegli di investire la tua scarsa capacità ingegneristica.

## Perché è importante

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

Valuta il **costo totale di proprietà**, non solo il prezzo della licenza: integrazione, manutenzione, assunzioni e costo opportunità degli ingegneri che non lavorano sul tuo prodotto.

## Esempio concreto

Un'azienda costruisce il suo motore di raccomandazione (il cuore del suo prodotto) ma acquista il suo CRM, l'elaborazione dei pagamenti e lo stack di logging. Costruire quelli brucerebbe gli ingegneri su lavoro non differenziante.

## Trade-off e insidie

- **Insidia:** sindrome del "not invented here", ricostruire commodities per ego o divertimento.
- **Insidia:** acquistare per una capacità core e non essere in grado di differenziarsi.
- Acquistare crea dipendenza dal fornitore; costruire crea debito di manutenzione. Scegli deliberatamente il tuo debito.

## Perché è importante

La capacità ingegneristica è la risorsa più scarsa nella maggior parte delle aziende.

Spenderla su commodities invece che su differenziatori è il modo più comune in cui i buoni team rimangono indietro.

Un build-vs-buy disciplinato è come un CTO indirizza quella capacità verso quello che effettivamente vince.