Мы семь месяцев писали свой Intercom. Поднимите руку, кто так делал
Про одну такую историю - и про то, как я теперь разговариваю со своими клиентами, когда они начинают мне объяснять, почему в их случае «писать лучше, чем купить».
В 2022 году у меня был клиент - продуктовая команда, человек пятнадцать, делали SaaS для HR-отдела. Нормальный бизнес, нормальная выручка, нормальная команда. И был у них проект: написать свой чат поддержки.
Я узнал об этом на второй неделе работы. CTO гордо показал мне канбан-доску, на которой среди прочих задач висел эпик. Эпик назывался «Customer Chat Platform». В нём было двадцать три тикета, четыре были закрыты, девятнадцать - в работе, разных степеней начатости.
-
Так, - сказал я. - А зачем?
-
Ну, - сказал CTO. - Мы не хотим зависеть от Intercom. У них дорого, у них ограничения по кастомизации, у них вендор-лок.
-
Сколько времени это займёт?
-
Ну, пару месяцев. Дальше допиливать по мере.
Проект длился семь месяцев. За это время было написано примерно 60% функциональности Intercom'а образца 2019 года. Из-за недооценки сложности (всегда) и других приоритетов (всегда), проект то делался, то откладывался, то снова делался. В какой-то момент в нём обнаружился баг, из-за которого сообщения терялись - только в мобильной Safari на iOS 15.3.1 и только если длина сообщения больше 400 символов. Этот баг чинили две недели.
На седьмом месяце они купили Intercom. CFO сел с CTO, они посчитали, вышло: за время разработки команда потратила около 4,5 миллиона рублей зарплатной стоимости (не включая кофе). Intercom стоил бы им в год примерно 700 000 рублей. За семь месяцев - 410 000.
Разница - 4,1 миллиона рублей. На это можно было нанять двух сильных сотрудников. Они их тогда и не наняли, потому что «пока не хватает бюджета».
Я эту историю рассказываю не чтобы обругать CTO. CTO был нормальный. Он честно хотел как лучше. Он просто попал в классическую ловушку: перепутал ядро продукта с обвязкой.
Ядро - это то, за что клиент вам платит, то, чем вы отличаетесь от конкурентов. У этого клиента ядром была HR-аналитика. Чат ядром не был.
Ядро на чужой платформе не живёт. Если вы покупаете «LMS-платформу» и строите на ней онлайн-школу, вы этой платформе конкурент, а не пользователь, и через год упрётесь в её потолок.
Всё остальное дешевле купить. Если вы пишете свой Stripe, свой Slack, свой Intercom, вы забираете на себя чужой бюджет разработки. Потому что Stripe тратит в год на инженерные усилия больше, чем весь ваш ежегодный бюджет. И они всё равно находят баги, которых у вас не будет времени найти.
Ядро или не ядро - на этот вопрос надо ответить до любого спора «написать или купить». Если ядро, дальше можно не читать. Если нет - читаем дальше, заранее склоняясь к SaaS.
Дальше идут ещё шесть вопросов, потому что не всё за пределами ядра стоит покупать и не всё ядро стоит писать с нуля.
Вопрос второй - сколько стоит «час на вопрос пользователя».
Готовый продукт работает сразу, но за него идёт подписка. Своя разработка заработает через несколько недель, и всё это время команда получает зарплату.
Простая прикидка: если годовая подписка меньше двух годовых зарплат разработчика, а продукт закрывает 80% потребности, берём SaaS.
Вопрос третий - есть ли в SaaS нужный API.
Купить Shopify - ок. Но если у вас склад в одной системе, касса в другом SaaS, а курьер - через самописную связку, ваша работа - склеить всё это через API. Проверяйте API до покупки. Если нужного метода нет, платить придётся дважды: за подписку и за прослойку между ней и остальными системами. Это худший из возможных раскладов.
Вопрос четвёртый - переживёт ли вендор ваш контракт.
SaaS-стартап с командой из десяти человек, обещающий решить всё, - это риск. Если они умирают через два года - вы теряете данные, логику, процесс. Миграция - болезненна.
Проверка: компания старше пяти лет? Есть ли Series B+? Есть ли документация миграции на конкурента? Если нет, вендор короткоживущий, и цена переезда будет высокой.
Вопрос пятый - данные.
В регулируемых отраслях (финтех, медицина, госсектор) это часто единственный решающий вопрос. Если SaaS не в нужной юрисдикции - пишем сами, без обсуждений.
В нерегулируемых - тоже думайте. Если на SaaS завязана критичная аналитика, а у вас нет экспорта, вы заложник вендора. Их повышение цен на 40% не обсуждается.
Вопрос шестой - насколько кастомный ваш процесс.
SaaS хорош, когда ваш процесс попадает в те 80%, что продукт поддерживает. Чем дальше от среднего - тем больше кастомизаций, плагинов и обходных решений. В какой-то момент вы тратите на кастомизацию больше, чем стоила бы своя разработка.
Правило простое: три кастомизации - норма, пять - повод насторожиться, десять - пора переезжать.
Вопрос седьмой - может быть, не надо выбирать.
2026 меняет правила. Раньше спор «писать или покупать» сводился к выбору между разработкой с нуля и готовой коробкой. Сейчас есть третий вариант: собрать из низкоуровневых кубиков.
- Backend API - Hono / FastAPI на 30 строк.
- БД - PostgreSQL у любого провайдера.
- Auth - Clerk / Supabase подключается за час.
- Queue - Temporal / Inngest.
- LLM - OpenAI / Anthropic API.
То, что три года назад стоило бы шесть месяцев разработки, сейчас собирается за три недели. Своя разработка теперь и состоит из кусков SaaS: пятая часть - собственная логика, остальное чужие кубики. Так сегодня собирают по умолчанию.
Вернёмся к тому CTO. Через год после истории с чатом мы с ним пересеклись на одной конференции. Я спросил, что они делают сейчас. Он ответил, что они вернули всю не-профильную работу на SaaS (Intercom, HubSpot, ClickUp), а свою команду сфокусировали на одном - на HR-аналитике. Рост выручки - плюс 60% за год.
«Я, - сказал он, - тот год учился одному уроку: инженерная работа - это не всегда написание кода. Иногда это решение его не писать».
Универсального ответа тут нет, а семь вопросов за пятнадцать минут переводят философский спор в решение, под которым есть аргументы.
Когда в следующий раз услышите «а давайте напишем сами / а давайте купим» - откройте этот чеклист. Он сэкономит вам недели и десятки тысяч.