Come si prendono le decisioni di build-vs-buy?

Question

Accepted Answer

**Build vs. buy** chiede se sviluppare qualcosa internamente o adottare un prodotto o servizio esistente. L'istinto di costruire è forte e spesso sbagliato, il costo reale della costruzione include anni di manutenzione, non solo la prima versione. La decisione dipende dal fatto che sia *core* per il tuo business.

## Perché è importante

```text
LEAN BUY when:                     LEAN BUILD when:
- It's NOT your core differentiator  - It IS your core value/differentiator
- A mature solution exists           - No good solution fits your needs
- Speed-to-market matters            - You need deep control/customization
- You lack expertise to maintain it  - Long-term cost of buying is prohibitive
- TCO of buying < building+upkeep     - Vendor lock-in is an unacceptable risk
```

## Un esempio concreto

Non costruire il tuo sistema di autenticazione, l'identità è complicata, critica per la sicurezza e non è il tuo differenziatore; acquista/integra un provider collaudato. *Fai* costruire il tuo motore di raccomandazione core se le raccomandazioni sono ciò che rende speciale il tuo prodotto. Costruisci ciò che ti rende *te*; acquista il resto.

## Conteggia il costo reale

I team sottostimano cronicamente la costruzione: la prima versione è il 20% del costo totale della vita. Manutenzione, patch di sicurezza, casi limite e on-call la superano di gran lunga. Conta il costo totale di proprietà nel corso degli anni, non la demo che puoi spedire in uno sprint.

## Una trappola

"Non inventato qui" porta a ricostruire problemi risolti; l'acquisto cieco porta a vendor lock-in e strumenti che non si adattano. Decidi deliberatamente, caso per caso.

## Perché è importante

Costruire la cosa sbagliata internamente consuma anni di sforzo ingegneristico in lavori non differenziati.

Ottenere questo risultato concentra il tuo scarso tempo ingegneristico su ciò che effettivamente fa vincere il business.