--- title: "Мы семь месяцев писали свой Intercom. Поднимите руку, кто так делал" url: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions" locale: "ru" author: "Mike Fluff" updated: "2026-02-09" description: "Продуктовая команда семь месяцев писала свой Intercom. Семь вопросов, которые я теперь задаю, прежде чем кто-то сядет писать то, что можно купить." tags: - "strategy" - "tech" - "ops" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions.md" --- # Мы семь месяцев писали свой Intercom. Поднимите руку, кто так делал > **Коротко:** Команда семь месяцев писала свой чат поддержки, потратила около 4,5 млн рублей зарплат и всё равно купила Intercom, который стоил бы 700 000 в год. Сначала я выясняю, входит ли задача в ядро продукта, за которое платит клиент. Если нет, SaaS выигрывает, когда закрывает 80% задачи, у него есть нужный API, вендор надёжен, данные лежат в нужной юрисдикции и кастомизаций меньше пяти. В 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. > **Быстрая оценка** > > Подписка за $500 в месяц - это $6к в год. Разработчик среднего уровня в ЕС или США > стоит $80-150к в год. Чтобы своя разработка окупилась, задача должна отнимать у него > не больше десятой части времени на протяжении пяти лет. Так бывает редко. **Вопрос третий - есть ли в 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: пятая часть - собственная логика, остальное чужие кубики. Так сегодня собирают по умолчанию. --- > **Как я теперь решаю за 15 минут** > > 1. **Это ядро продукта?** Да - пишем сами или собираем из кубиков. Нет - идём дальше. > 2. **Есть SaaS, закрывающий 80% задачи?** Да - идём дальше. Нет - пишем сами. > 3. **API есть, вендор живой, данные лежат где надо?** Все три «да» - берём SaaS, > хоть одно «нет» - пишем сами. > 4. **Процесс сильно кастомный?** Да - сами или кубики. Нет - SaaS. --- Вернёмся к тому CTO. Через год после истории с чатом мы с ним пересеклись на одной конференции. Я спросил, что они делают сейчас. Он ответил, что они вернули всю не-профильную работу на SaaS (Intercom, HubSpot, ClickUp), а свою команду сфокусировали на одном - на HR-аналитике. Рост выручки - плюс 60% за год. «Я, - сказал он, - тот год учился одному уроку: инженерная работа - это не всегда написание кода. Иногда это решение его не писать». Универсального ответа тут нет, а семь вопросов за пятнадцать минут переводят философский спор в решение, под которым есть аргументы. Когда в следующий раз услышите «а давайте напишем сами / а давайте купим» - откройте этот чеклист. Он сэкономит вам недели и десятки тысяч. **[Обсудить архитектурное решение](https://www.mikefluff.com/ru#contact)** — Если спор «написать или купить» крутится в вашей команде уже третий месяц - приходите, разберём с аргументами. Я видел оба сценария, в том числе закрытие собственной разработки на поздней стадии.