Como você toma decisões de build-vs-buy em escala organizacional?

Question

Accepted Answer

O princípio central é simples: **construa o que o diferencia, compre todo o resto.** Em escala organizacional, a decisão é menos sobre uma única ferramenta e mais sobre onde você escolhe gastar sua capacidade de engenharia escassa.

## Uma estrutura de decisão

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

Pondere **custo total de propriedade**, não apenas o preço da licença: integração, manutenção, contratação e custo de oportunidade dos engenheiros não trabalhando no seu produto.

## Exemplo concreto

Uma empresa constrói seu mecanismo de recomendação (o coração do seu produto), mas compra seu CRM, processamento de pagamentos e stack de logging. Construir essas coisas queimaria engenheiros em trabalho não diferenciador.

## Trade-offs e armadilhas

- **Armadilha:** síndrome de "não foi inventado aqui", reconstruindo commodities por ego ou diversão.
- **Armadilha:** comprar para uma capacidade central e ser incapaz de se diferenciar.
- Comprar cria dependência de fornecedor; construir cria dívida de manutenção. Escolha sua dívida deliberadamente.

## Por que isso importa

Capacidade de engenharia é o recurso mais escasso na maioria das empresas.

Gastá-lo em commodities em vez de diferenciadoras é a forma mais comum de bons times ficarem para trás.

Um build-vs-buy disciplinado é como um CTO direciona essa capacidade para o que realmente vence.