Есть бизнесы, которые растут красиво. Продажи идут, заявок и клиентов становится больше, команда бодрится, собственник смотрит на график выручки и уже мысленно выбирает, в какой кофейне будет говорить фразу: "Мы просто хорошо попали в рынок".
А потом открывается юнит-экономика. И там не бизнес, а финансовая трагикомедия. Выручка растёт, а прибыль почему-то делает вид, что её не приглашали.
Потому что вместе с каждым новым клиентом растёт не только доход. Растут комиссии, подписки, сервисы, лимиты, пользователи, события, заявки, письма, API-вызовы, сообщения, хранилище, автоматизации и ещё семь пунктов, которые в тарифе были написаны мелким шрифтом, как побочные эффекты у лекарства.
Сначала сервис стоил всего 10 долларов в месяц, потом всего 10 долларов за пользователя. Потом вы захотели аналитику, интеграции, историю, API и чтобы кнопка не смотрела на вас с презрением, а это уже тариф Бизнес.
И вот уже SaaS ведёт себя как очень вежливый налоговый инспектор:
Поздравляем с ростом. Теперь платите больше.
Главная проблема: сервисы часто сидят не в постоянных расходах, а в переменных
Когда бизнес смотрит на подписки, он часто воспринимает их как операционные расходы.
Ну есть CRM, сервис рассылок, телефония, аналитика, платформа для обучения, сервис записи, облако, AI-инструмент и так далее. Кажется, что это просто расходы на инфраструктуру. Но в юнит-экономике важно другое:
Расход фиксированный или он растёт вместе с каждым клиентом, заказом, пользователем, лидом, сообщением, оплатой или обработанным событием?
Если сервис стоит 20 000 рублей в месяц независимо от объёма, это один разговор. Если сервис берёт оплату:
- за пользователя;
- за заявку;
- за сделку;
- за контакт в базе;
- за отправленное сообщение;
- за событие;
- за API-запрос;
- за обработанный документ;
- за объём хранилища;
- за транзакцию;
- за активного клиента,
то это уже не просто подписка, переменная или условно-переменная стоимость. А переменные расходы напрямую влияют на маржу юнита. Если совсем просто:
Маржа юнита = доход с одного юнита - переменные расходы на юнит - (постоянные расходы / количество юнитов)
Если сервисы забирают кусок с каждого юнита, то масштабирование может стать странным аттракционом. Вы растёте, сервис растёт, вы радуетесь, сервис тоже радуется, но с вашей карты.
Почему это опасно при масштабировании
Давайте разберём на примере. Допустим, у бизнеса есть продукт. Один клиент приносит 10 000 рублей выручки. На первый взгляд всё неплохо. Но теперь считаем расходы:
Эквайринг: 300
Привлечение клиента: 2 000
Комиссия платформы: 500
Обработка клиента: 150
Сервис рассылок и уведомлений: 80
Поддержка: 120
AI и автоматизация: 100
Операционная работа: 700
Итого переменные расходы: 3 950
Постоянные расходы для примера: 1 000
Вроде терпимо. Маржинальный доход при 100 клиентах:
10 000 - 3 950 - (1000 / 100) = 6 040 рублей
Теперь бизнес хочет масштабироваться. Было 100 клиентов в месяц. Стало 1 000. Выручка выросла:
100 * 10 000 = 1 000 000 рублей1 000 * 10 000 = 10 000 000 рублей
Красиво. Можно уже сделать презентацию с графиком вверх и фразой "кратный рост бизнеса". Но переменные расходы тоже выросли:
100 * 3 950 = 395 0001 000 * 3 950 = 3 950 000
И бизнес не получает полноценный эффект масштаба. Он не строит актив. Он арендует способность обслуживать рост.
Это как бежать быстрее на дорожке в спортзале, где за каждый шаг списывается отдельная комиссия.
Спортивно. Дорого. Местами унизительно.
Где сервисы портят юнит-экономику
Сервисы особенно опасны для юнит-экономики, когда они встроены в ключевой процесс и тарифицируются от объёма. Вот типичные зоны:
1. CRM и продажи
CRM часто тарифицируется по пользователям, контактам, функциям, автоматизациям, интеграциям или продвинутой аналитике.
- Если отдел продаж растёт, стоимость CRM растёт;
- Если база клиентов растёт, тариф может вырасти;
- Если нужны интеграции, доплачиваем;
- Если нужна нормальная аналитика, доплачиваем;
- Если нужно, чтобы CRM не выглядела как археологический экспонат из эпохи "установите Windows 98", тоже иногда доплачиваем.
Сама по себе CRM не плохая. Плохая ситуация — когда CRM стала обязательной частью обработки каждого лида, но её стоимость и ограничения не учтены в экономике сделки.
2. Рассылки, уведомления и мессенджеры
Письма, SMS, WhatsApp, Telegram-уведомления, push, чат-боты — всё это часто считается по объёму.
- Один клиент получил цепочку из 12 сообщений;
- Тысяча клиентов получили 12 000 сообщений.
И внезапно "копеечные уведомления" превращаются в отдельную статью переменных расходов. Особенно весело, когда половина сообщений не влияет на продажу, но исправно влияет на счёт.
Маркетинг такой: "Мы прогреваем аудиторию".
Финансы такие: "Вы нагрели наш счёт".
3. Платформы для обучения, записи, бронирований, каталогов
Многие платформы берут оплату за активных пользователей, бронирования, участников, транзакции или расширенные модули.
На маленьком объёме это удобно. На большом объёме возникает вопрос:
Мы платим за ценность или просто каждый месяц покупаем право пользоваться процессом, который уже давно стал нашим основным активом?
Если бизнес работает вокруг этого процесса, чужая платформа может стать дорогой арендой собственного роста.
4. Аналитика и BI
Аналитика может тарифицироваться по пользователям, источникам данных, событиям, объёму хранения, обновлениям, коннекторам.
Ирония в том, что бизнес платит за аналитику, чтобы лучше считать деньги, но саму стоимость аналитики часто не считает.
5. AI-сервисы и автоматизация
AI выглядит магически. Сначала особенно.
"Смотри, агент сам отвечает клиентам";
"Смотри, он сам пишет описания";
"Смотри, он сам классифицирует заявки".
А потом приходит отчёт об использовании. Токены, запросы, документы, изображения, голос, поиск, векторная база, логи и ретраи, потому что агент решил быть творческой личностью.
AI может сильно снижать расходы. Но если не считать стоимость обработки одного действия, он может стать очень красивым способом сжигать маржу.
Когда SaaS нормален, а когда становится проблемой
Готовые сервисы — это не зло. Иногда SaaS — лучший вариант.
- Он быстро запускается;
- У него есть поддержка;
- Его не нужно разрабатывать;
- Он уже закрыл типовые сценарии;
- Он позволяет проверить гипотезу без капитальных затрат.
Если бизнес на старте, покупать готовое решение часто разумнее, чем строить своё. Проблема начинается, когда выполняются три условия:
- Сервис встроен в ключевой процесс;
- Его стоимость растёт вместе с объёмом;
- Процесс уже понятен и повторяется.
Вот здесь надо остановиться и посчитать. Потому что если вы платите сервису с каждого клиента, сделки, заявки, пользователя или события, то этот сервис сидит в переменных расходах. А переменные расходы режут маржу на каждом юните.
При маленьком объёме это терпимо. При большом — начинает мешать росту.
Простой пример: когда своя разработка становится выгоднее
Допустим, компания использует внешний сервис для клиентского кабинета. Он стоит:
- 50 000 рублей в месяц базово;
- плюс 80 рублей за активного клиента;
- плюс 20 000 рублей за расширенную аналитику;
- плюс 15 000 рублей за интеграции;
- плюс иногда подрядчик за донастройки.
На 500 активных клиентов: 50 000 + 500 * 80 + 20 000 + 15 000 = 125 000 рублей в месяц
На 3 000 активных клиентов: 50 000 + 3 000 * 80 + 20 000 + 15 000 = 325 000 рублей в месяц
На 10 000 активных клиентов: 50 000 + 10 000 * 80 + 20 000 + 15 000 = 885 000 рублей в месяц
И это без учёта ручной работы, ограничений платформы и того факта, что где-то в тарифе уже притаился менеджер по продажам с фразой "вам нужно энтерпрайс решение".
Теперь сравним с разработкой собственного решения. Например:
- разработка первой версии: 2 500 000 рублей;
- поддержка и развитие: 150 000 рублей в месяц;
- инфраструктура: 30 000 рублей в месяц;
- период оценки: 12 месяцев.
Годовая стоимость собственного решения:
2 500 000 + (150 000 + 30 000) * 12 = 4 660 000 рублей
Годовая стоимость внешнего сервиса:
При 500 пользователей:
Месячная стоимость 125 000 рублей
Годовая стоимость 1 500 000 рублей
При 3 000 пользователей:
Месячная стоимость 325 000 рублей
Годовая стоимость 3 900 000 рублей
При 10 000 пользователей:
Месячная стоимость 885 000 рублей
Годовая стоимость 10 620 000 рублей
И делаем выводы для этого конкретного случая:
- При 500 клиентах свой продукт, скорее всего, рано.
- При 3 000 клиентах уже нужно внимательно считать.
- При 10 000 клиентах вопрос становится другим:
Почему ключевой процесс бизнеса всё ещё работает как арендованная квартира с помесячной оплатой за каждого гостя?
И вот здесь разработка своего решения может быть не капризом, не "давайте сделаем красиво", не мечтой внутреннего технаря построить свой маленький космодром. Она может стать нормальным экономическим решением.
Что меняется в юнит-экономике, когда появляется своё решение
Главный эффект собственной разработки не в том, что "теперь бесплатно". И это важный момент. Своё решение не бесплатно.
Его нужно:
- разработать;
- поддерживать;
- обновлять;
- защищать;
- мониторить;
- развивать;
- документировать;
- иногда чинить в пятницу вечером, потому что бизнес любит проверять зрелость команды ближе к выходным.
Но у своего решения может быть другой профиль расходов. Вы переводите часть переменных расходов в фиксированные или условно фиксированные.
Было: каждый новый клиент = новая плата сервису
Стало: есть стоимость разработки и поддержки, а предельная стоимость нового клиента ниже.
Это может сильно улучшить маржинальность при росте. Особенно если:
- клиентов много;
- процесс повторяемый;
- логика понятная;
- сервисы берут оплату за объём;
- готовые решения плохо подходят;
- данные критичны;
- у бизнеса есть планы масштабирования.
Собственная разработка в такой ситуации становится не расходом "на IT", а инвестицией в снижение переменной себестоимости. Если говорить языком юнит-экономики:
Вы не просто заменяете сервис. Вы снижаете переменные расходы на юнит и повышаете потенциальную маржу при масштабировании.
Но своё решение не всегда оптимально
Здесь важно не уйти в другую крайность. Вот плохая логика:
"Сервисы дорогие, всё пишем сами".
Это путь к внутренней платформе, которую через полгода будут бояться трогать, как старый Excel-файл. Своя разработка не нужна, если:
- объём маленький;
- процесс ещё не проверен;
- требования постоянно меняются;
- готовый сервис хорошо закрывает задачу;
- стоимость подписки не влияет на маржу;
- нет внутреннего владельца продукта;
- нет бюджета на поддержку;
- задача не является критичной для бизнеса.
Собственное решение выгодно не тогда, когда сервис "раздражает". Оно выгодно, когда есть математика.
Как понять, что своё решение стало оптимальным
Есть несколько признаков:
1. Сервисная стоимость растёт пропорционально объёму
Чем больше клиентов, заказов, пользователей, заявок или событий, тем больше вы платите.
Если рост выручки автоматически увеличивает счёт за сервис, нужно смотреть, не съедает ли он маржу.
2. Сервис сидит в ключевой операции
Если через сервис проходит основная ценность бизнеса — заявки, кабинет клиента, обучение, запись, поддержка, документы, аналитика, обработка заказов — это уже не вспомогательный инструмент.
Это часть продукта или операционной модели.
3. Процесс стабилизировался
Пока вы ищете процесс, готовый сервис лучше. Когда процесс понятен, повторяется и уже доказал ценность, можно думать о своём решении. Но не раньше.
Разработка хаоса даёт хаос, только с логотипом компании.
4. Готовый сервис заставляет платить за лишнее
Вам нужны 3 функции, но вы платите за 70. Или нужна одна нестандартная логика, ради которой приходится покупать дорогой тариф.
Или сервис решает типовую задачу, а бизнес уже давно вырос из типовой логики.
5. Сервис ограничивает рост
Например:
- нельзя нормально интегрировать данные;
- нет нужных API;
- слабая аналитика;
- неудобный кабинет для клиентов;
- дорого масштабировать пользователей;
- нельзя быстро менять сценарии;
- все доработки зависят от чужой дорожной карты.
Если ваш рост зависит от чужой дорожной карты, это уже не просто продуктовая зависимость. Это подписка на ожидание.
Какие варианты есть перед собственной разработкой
Своя разработка — не первый шаг. Перед ней есть несколько промежуточных решений.
1. Оптимизировать текущий сервис
Можно:
- поменять тариф;
- убрать лишних пользователей;
- отключить модули;
- настроить роли;
- почистить базу;
- пересобрать процесс;
- договориться об индивидуальных условиях.
Иногда это даёт быстрый эффект без разработки. Скучно. Зато работает. А бизнесу иногда полезно скучное. Оно часто прибыльнее презентации с 3D-иконками.
2. Заменить сервис
Если текущий сервис не подходит, можно выбрать другой.
Плюсы:
- быстрее, чем разработка;
- дешевле на старте;
- есть готовая поддержка;
- можно закрыть типовой процесс.
Минусы:
- миграция данных;
- обучение команды;
- снова подписка;
- риск повторить ту же проблему через год.
3. Связать сервисы интеграциями
Если основная боль в том, что сервисы не разговаривают друг с другом, интеграции могут быть лучшим решением.
Плюсы:
- сохраняются привычные инструменты;
- быстро убирается ручной труд;
- можно улучшить аналитику;
- не нужно сразу менять весь стек.
Минусы:
- интеграции нужно поддерживать;
- плохой процесс не спасут вебхуки;
- сложная связка может стать отдельным техническим долгом.
4. Собрать no-code / low-code слой
n8n, Make, Albato и похожие инструменты хорошо подходят для проверки автоматизации.
Плюсы:
- быстро;
- дешевле разработки;
- можно проверить гипотезу;
- удобно автоматизировать повторяющиеся операции.
Минусы:
- сложная логика становится хрупкой;
- нужен человек, который понимает процесс;
- ошибки могут масштабироваться так же быстро, как автоматизация;
- при росте может понадобиться нормальная архитектура.
5. Сделать небольшой внутренний инструмент
Не обязательно сразу строить большую платформу. Иногда достаточно:
- внутренней админки;
- простого кабинета;
- обработчика заявок;
- дашборда;
- скрипта сверки данных;
- бота для менеджеров;
- конфигуратора;
- инструмента генерации документов;
- связки CRM, сайта и аналитики.
Это может быть первым шагом к своему продукту без большой ставки.
Как считать решение: SaaS или своё
Упрощённая логика такая.
Шаг 1. Посчитать текущую стоимость
Стоимость SaaS в год =
подписка
+ плата за пользователей / клиентов / события
+ внедрение
+ доработки
+ поддержка
+ ручная работа
+ ошибки и потери
Шаг 2. Посчитать стоимость своего решения
Стоимость своего решения в первый год =
разработка
+ поддержка
+ инфраструктура
+ развитие
+ управление продуктом
Шаг 3. Посчитать точку безразличия
Это момент, когда своё решение начинает стоить не дороже внешнего сервиса.
Пример:
- SaaS сейчас стоит 300 000 рублей в месяц и растёт с объёмом;
- своё решение стоит 3 000 000 рублей разработки и 180 000 рублей в месяц поддержки и инфраструктуры.
Год SaaS: 300 000 * 12 = 3 600 000
Год своего решения: 3 000 000 + 180 000 * 12 = 5 160 000
В первый год своё дороже. Но если через рост SaaS станет стоить 600 000 рублей в месяц: 600 000 * 12 = 7 200 000
Тогда своё решение уже выглядит иначе. Не потому что оно модное. А потому что на масштабе меняется экономика.
Самая частая ошибка в расчётах
Бизнес сравнивает подписку SaaS в месяц со стоимостью разработки и делает вывод, что "Разработка дорогая". Это неправильное сравнение. Нужно сравнивать не месячную подписку с проектом разработки, а стоимость владения SaaS на горизонте 12-36 месяцев со стоимостью создания, поддержки и развития своего решения на том же горизонте.
Плюс учитывать влияние на маржу юнита. Потому что если SaaS сидит в переменных расходах, он будет забирать деньги с каждого нового клиента. А своё решение может потребовать больше денег на входе, но снизить стоимость обслуживания каждого следующего клиента. Это и есть момент, где юнит-экономика начинает говорить: "Ребята, может, хватит уже арендовать собственный процесс?"
Что в итоге
Сторонние сервисы — нормальный инструмент для старта, проверки гипотез и закрытия типовых задач. Но если расходы на сервисы сидят в переменных расходах, масштабирование может стать не таким привлекательным, как кажется.
- Бизнес растёт.
- Выручка растёт.
- Команда растёт.
- Сервисные счета растут.
А маржа стоит в углу и делает вид, что просто пришла посмотреть. В какой-то момент нужно пересчитать:
- какие сервисы реально нужны;
- какие расходы относятся к каждому клиенту или заказу;
- что происходит с маржей при росте;
- какие сервисы можно оптимизировать;
- какие можно связать;
- какие заменить;
- где no-code или low-code достаточно;
- где собственное решение становится экономически сильнее подписочной модели.
Своё решение не всегда нужно. Но если сторонний сервис стал частью переменной себестоимости, растёт вместе с каждым юнитом и ограничивает масштабирование, разработка собственного инструмента может быть не "дорогой разработкой", а способом улучшить юнит-экономику. И это уже совсем другой разговор.
Не "давайте напишем своё, потому что надоело платить", а:
Давайте снизим переменные расходы, повысим маржу юнита и построим актив, который не дорожает каждый раз, когда бизнес растёт
Если у вас растёт выручка, но прибыль не радуется вместе с ней, посмотрите не только на рекламу, продажи и команду.
Посмотрите на сервисы.
Возможно, часть из них сидит в переменных расходах и ухудшает юнит-экономику при масштабировании.
Мы в Гигоном можем разобрать ваш сервисный стек, посчитать, где подписки и тарифы за использование съедают маржу, и показать варианты:
- оставить как есть;
- оптимизировать тарифы;
- связать сервисы интеграциями;
- собрать no-code / low-code автоматизацию;
- заменить платформу;
- разработать собственный инструмент без подписочной модели.
Не ради разработки, а ради нормальной экономики роста. Потому что масштабирование должно увеличивать бизнес, а не только счёт за SaaS.
Запишись на аудит готовности к росту. Сейчас это бесплатно и даёт понимание как расти.
