Build vs buy: финансовая модель, в которой ошибается большинство
CTO смотрит на квоту SaaS-биллинга: $52K в год. В переговорной четверо инженеров, каждый стоит примерно $7K/мес. с учётом нагрузки. Математика моментальная: «4 инженера × 4 месяца = 16 человеко-месяцев. Соберём своё за $112K. Дальше бесплатно навсегда». Совет директоров кивает. Закупкам говорят отменить SaaS-evaluation. Через восемнадцать месяцев команда всё ещё владеет своим биллингом, двое инженеров поддерживают его в полставки, а первоначальные четверо в тот квартал не отгрузили ни одной revenue-фичи. Реальная 5-летняя стоимость «build» оказывается $546K, почти вдвое больше SaaS-пути. Forrester в анализе Total Economic Impact of Buy-vs-Build (2023) фиксирует медианное занижение стоимости in-house на 2,3×. Gartner повторяет это в своих TCO-фреймворках уже пятнадцать лет. Большинство команд всё равно не дочитывает математику до конца.
{/* truncate */}
Сравнение, которое реально проводят команды
Заходишь на встречу build vs buy и видишь на доске вот это:
| Сторона | Что считают |
|---|---|
| Buy | SaaS-подписка (годовая строка бюджета) |
| Build | Инженеры × месяцы × loaded rate |
Всё. Два числа. Buy выглядит дорогим, потому что у него висит recurring price tag. Build выглядит дешёвым, потому что зарплаты «и так уже платим». Решение принимают раньше, чем кто-либо подвергает модель сомнению.
Модель неверна с обеих сторон. Build она занижает в 2-3×, buy недосчитывает с меньшей погрешностью. Перекос асимметричный. Чистый итог: build выигрывает там, где не должен был.
Что включает честное сравнение
Вот что упускают:
| Компонент стоимости | Build | Buy |
|---|---|---|
| Прямые часы разработки | учитывается | n/a |
| Loaded overhead (коэффициент K) | обычно упускают | n/a |
| Поддержка навсегда (0,3-0,7 FTE) | обычно упускают | минимально |
| Opportunity cost (инженеры не на revenue-работе) | почти всегда упускают | n/a |
| Подписка / лицензия | n/a | учитывается |
| Стоимость интеграции (разовая) | n/a | иногда упускают |
| Customization tax (постоянный) | n/a | обычно упускают |
| Vendor risk (рост цен, sunset) | n/a | редко моделируют |
| Switching cost при провале вендора | n/a | почти всегда упускают |
Колонки ошибаются по-разному. Build не учитывает recurring-затраты (поддержка, opportunity); Buy не учитывает risk-adjusted затраты (vendor lock-in, customization). Долларовый эффект build-промахов обычно крупнее: они компаундируются за весь срок жизни актива.
Четыре скрытых стоимости «build»
1. Loaded rate, а не «зарплата делённая на часы»
Инженер за $5,000/мес. не стоит $5,000. Он стоит $5,000 плюс долю EM, плюс DevOps-инженера, который держит CI живым, плюс HR-партнёра, плюс офис, лицензии и планёрки. Стандартная бухгалтерская формула: loaded_rate = direct_rate × (1 + K), где K обычно 0,3–0,6 в зависимости от компании. Мы разобрали математику в Loaded Hourly Rate: почему ваш инженер стоит на 50% больше зарплаты. Если в build-оценке используется голая зарплата, умножайте на 1,4 сразу. Часто только этого достаточно, чтобы решение перевернулось.
2. Поддержка навсегда, а не «потом разберёмся»
Внутренние инструменты не «выходят и заканчиваются». Они выходят и начинают долгий тихий tail of maintenance. Зависимая библиотека релизит security-патч, кто-то апдейтит. Меняется minor-версия Postgres, кто-то перетестирует. Сейлз-менеджер звонит финансам с вопросом, почему у одного клиента ломается инвойс, кто-то дебажит. Эмпирическое правило индустрии: 0,3–0,7 FTE на сервис в год. Стабильно. Навсегда.
На горизонте 5 лет при 0,5 FTE × $7K/мес. loaded × 12 = $42K/год × 5 = $210K. Эта цифра почти никогда не появляется в первоначальной build-оценке.
3. Opportunity cost: инженеры не бесплатные
Четыре инженера, которые четыре месяца сидят на внутреннем биллинге, это четыре инженера, которые четыре месяца не делают следующую платную фичу. Стоимость этого разрыва есть Cost of Delay на то, что они могли бы строить, обычно $10-20K на инженера в неделю для B2B SaaS-команды с активным пайплайном. Консервативно: 4 инженера × 16 недель × $14K/нед. медианного CoD на инженер-эквивалент = $224K revenue или пайплайна, который просто не открывается, пока команда сидит головой в plumbing.
a16z в State of SaaS Adoption 2023 формулирует это прямо: сильнейший предиктор скорости роста B2B-стартапа не размер инжкоманды, а то, насколько команда защищает своих немногочисленных инженеров от undifferentiated work. «Соберём сами» на коммодити-функциональности — канонический капкан undifferentiated-работы.
4. Плоский K врёт
Множитель 1,4× на стоимость build лучше, чем ничего, но K меняется во времени. Сезонность мы разобрали в Cost per Feature: формула на SQL, которая работает в проде. Для честной 5-летней TCO-модели берите средний помесячный K по конкретной команде, а не плоское индустриальное число. Обычно расхождение 5-15% в любую сторону.
Реальный worked example
B2B SaaS-компания оценивает внутренний биллинг-сервис. Два пути.
Путь A: Buy (Stripe Billing или аналогичный вендор)
| Год | Подписка | Интеграция | Итого |
|---|---|---|---|
| Y1 | $52,000 | $15,000 (разовая) | $67,000 |
| Y2 | $52,000 | 0 | $52,000 |
| Y3 | $52,000 | 0 | $52,000 |
| Y4 | $52,000 | 0 | $52,000 |
| Y5 | $52,000 | 0 | $52,000 |
| Итого 5 лет | $260,000 | $15,000 | $275,000 |
Путь B: Build
| Компонент | Расчёт | Стоимость |
|---|---|---|
| Initial dev | 4 инженера × 4 месяца × $7K loaded | $112,000 |
| Поддержка | 0,5 FTE × $7K × 12 × 5 лет | $210,000 |
| Opportunity cost | 4 инженера × 16 недель × $14K/нед. CoD | $224,000 |
| Итого 5 лет | $546,000 |
5-летний TCO. Buy: один фиолетовый блок подписки и небольшая розовая надбавка на интеграцию. Build стэкает initial dev, поддержку и слой opportunity cost, который команды забывают считать.
Два числа рядом: $275K против $546K. Интуиция «build дешевле» промахивается на $271K, или 99% от стоимости buy. И это до vendor-risk поправок на стороне buy.
Опытный CTO захочет оспорить строку opportunity cost. Хорошо, уберём её. Build всё равно стоит $322K против $275K за buy. Buy всё равно выигрывает $47K. Один только tail of maintenance переворачивает решение; opportunity cost просто делает зазор очевидным.
Где этот расчёт живёт в операционной системе
Большинство компаний обнаруживает разрыв ретроспективно. Кто-то пересматривает 5-летний внутренний инструмент, прогоняет цифры, получает честный ответ и понимает, что делать уже нечего; деньги потрачены.
Решение: считать build-vs-buy той же машинкой, что и любую другую инженерную стоимость. PanDev Metrics трекает activity_events по фиче; та же агрегация времени, которая считает cost per feature для in-house работы, считает и стоимость интеграции для vendor-проекта. Тот же SQL, тот же K-коэффициент, те же часовые ставки. Когда CTO спрашивает «во что нам встала интеграция со Stripe и во что бы встал Stripe Billing, если бы мы строили его сами?», данные уже есть, чтобы ответить честно.
Это работает на калибровку. Первая build-vs-buy оценка команды всегда догадка. К третьей, если две предыдущие были замерены реальной телеметрией, оценка становится острой. «Сказали, что интеграция SSO займёт 6 недель. Заняла 11. В следующий раз, говоря 6, знаем, что надо удвоить».
Vendor risk: где build всё ещё выигрывает
Модель выше не есть призыв всё аутсорсить. Есть случаи, когда build выигрывает и по TCO:
- Mission-critical инфра, где даунтайм вендора означает ваш даунтайм, а SLA-штрафы не покрывают репутационный ущерб.
- Core product differentiation: всё, ради чего клиенты покупают именно ваш продукт. По определению это инвестиция, а не undifferentiated работа.
- Регуляторные контексты (ФЗ-152, HIPAA, on-prem only), где вендоры физически не могут обслужить use case.
- Нишевые вендоры без потолка ценообразования: маленькие инструменты, где вендор может поднять цену в 10× через год, и придётся либо платить, либо переписывать.
Bessemer в State of the Cloud 2024 фиксирует канонический паттерн: топ-квартиль B2B SaaS-компаний тратит в среднем 18% хедкаунта на differentiating-функциональность и 82% на коммодити-работу, и для каждого коммодити-сегмента спрашивает, нельзя ли купить вместо построить. Успешные агрессивно выносят эти 82% наружу.
Двухстрочное правило: build for moats, buy for plumbing. Биллинг-движок, feature-flag сервис, мониторинг-дашборд, CRM, всё это plumbing. Pricing-движок, кодирующий вашу уникальную бизнес-модель; рекомендательный алгоритм, определяющий продукт; latency-критичный путь, который чувствуют клиенты, это moats. Не аутсорсьте moats. Не стройте plumbing.
Что модель не скажет
Расчёт предполагает, что SaaS-вендор будет существовать через пять лет и не устроит ценовой хайк в стиле GitLab или sunset-объявление. Vendor risk реален. Не пытаемся вкручивать его как probability-множитель в TCO-строку; это создаёт фальшивую точность. Честная формулировка: добавьте 15-25% к колонке buy как vendor-risk резерв, и даже с этим резервом модель всё равно склоняет к покупке для большинства категорий plumbing.
Второй лимит: статья оперирует 5-летним горизонтом. Если у бизнеса есть чёткий 10-летний роадмап и инструмент вряд ли заменят, tail of maintenance к 7-му году агрессивнее давит в пользу build. У нас нет IDE-телеметрии на 10-летние внутренние инструменты; к этому времени большинство из них уже задепрекейтили или вытеснили покупными.
CTO, который выигрывает этот спор, не тот, кто доказал, что build дешевле. Это тот, кто прогнал сравнение со всеми четырьмя скрытыми затратами в колонке build, со строками интеграции и риска в колонке buy, и дал числам осесть. В большинстве случаев SaaS-строка оказывается дешёвой опцией ровно на тот размер экономии, на который команда рассчитывала, когда выбирала build. Заходите с открытыми глазами в каждое решение и понимайте, по какую сторону линии «moats vs plumbing» оно сидит.