Как принимать решения build-vs-buy на уровне организации?

Question

Accepted Answer

Основной принцип прост: **строите то, что вас отличает, покупаете всё остальное.** На уровне организации решение касается не столько одного инструмента, сколько выбора того, куда вы направляете скудный инженерный потенциал.

## Рамка принятия решения

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

Учитывайте **полную стоимость владения**, а не только цену лицензии: интеграция, поддержка, наём и упущенная выгода инженеров, не работающих над вашим продуктом.

## Конкретный пример

Компания разрабатывает собственный механизм рекомендаций (сердце её продукта), но закупает CRM, обработку платежей и стек логирования. Разработка этого сожгла бы инженеров на неличных работах.

## Компромиссы и подводные камни

- **Подводный камень:** синдром «не изобретено здесь» — переразработка стандартных решений из эго или развлечения.
- **Подводный камень:** закупка для основной возможности и неспособность дифференцироваться.
- Закупка создаёт зависимость от поставщика; разработка создаёт технический долг. Выбирайте свой долг осознанно.

## Почему это важно

Инженерный потенциал — самый дефицитный ресурс в большинстве компаний.

Тратить его на стандартные решения вместо дифференциаторов — самый частый способ, которым хорошие команды отстают.

Дисциплинированный подход build-vs-buy — это то, как CTO направляет этот потенциал на то, что действительно побеждает.