Вопрос «SaaS или своя система» звучит как развилка. На практике компания одновременно держит готовую CRM, 1С, облачную почту и собственный кабинет дилера.
Единой доли 65/35 не существует: границы размыты. Исследования описывают стратегию buy, build and blend — покупать, создавать и смешивать.
10 признаков, что подписка не закрывает процесс, — в интервью про micro-SaaS. Когда индивидуальная разработка избыточна — в материале когда Laravel не нужен.
Содержание
Когда компании требуется CRM, складская система, личный кабинет клиента или инструмент для внутренних процессов, возникает стандартный вопрос:
Купить готовый SaaS или разработать собственную систему?
Интуитивно может показаться, что большинство компаний используют готовые сервисы, а собственная разработка встречается только у крупных корпораций.
На практике граница гораздо менее чёткая.
Современная B2B-компания часто одновременно использует:
Поэтому реальный выбор обычно выглядит не как:
SaaS или собственная разработка
а как:
что купить готовым, что разработать самостоятельно и как всё это связать между собой.
Единой статистики, которая позволила бы сказать:
65% B2B-компаний используют SaaS, а 35% — собственные системы,
не существует.
Причина проста: границы слишком размыты.
Если компания использует готовый Bitrix24, но разработала собственный кабинет дилера — к какой категории её относить?
А если используется стандартная ERP, но вокруг неё создано десять внутренних приложений?
Или SaaS был сильно доработан через API?
Поэтому исследования обычно изучают не долю «полностью собственных» компаний, а стратегию build vs buy — разрабатывать программное обеспечение или покупать готовое.
И исследования последних лет показывают важную тенденцию: большинство компаний не выбирают только один вариант.
Например, Gartner описывает современный подход уже не просто как «build or buy», а как buy, build and blend — покупать, создавать и комбинировать разные решения.
Одно из исследований 200 европейских компаний, опубликованное Modeso в 2025 году, показало, что около 70% опрошенных организаций полностью или частично используют самостоятельно разработанное программное обеспечение, а не полагаются исключительно на готовые SaaS-продукты. Важно учитывать, что это выборка enterprise-компаний, поэтому переносить этот показатель на весь малый и средний бизнес нельзя.
Ещё более интересные данные появились в 2026 году.
Retool опросил 817 разработчиков и сотрудников компаний, использующих внутренние программные инструменты. 35% респондентов сообщили, что их команды уже заменили хотя бы один SaaS-продукт собственной разработкой. 78% ожидали увеличения количества собственных внутренних инструментов в течение 2026 года.
Но это тоже не означает, что компании массово отказываются от SaaS.
Выборка Retool связана с разработчиками и пользователями платформы создания внутренних приложений, поэтому в ней собственная разработка закономерно представлена сильнее, чем в среднем по бизнесу.
Другой опрос — среди специалистов по данным — показал противоположную на первый взгляд картину: 61% команд придерживались стратегии buy first, build selectively.
То есть:
сначала ищем готовый инструмент, а собственную систему создаём только там, где она действительно нужна.
Главными причинами разработки были контроль и возможность кастомизации, а главными причинами покупки — скорость внедрения и отсутствие необходимости самостоятельно поддерживать систему.
Если объединить эти результаты, становится виден общий паттерн:
SaaS остаётся стандартным решением для типовых функций, а собственная разработка чаще используется там, где процесс компании отличается от стандартного.
Представим небольшую B2B-компанию.
Она продаёт оборудование другим организациям.
Её технологический стек может выглядеть так:
Сайт на готовой CMS Bitrix24 1С Google Sheets облачная телефония сервис email-рассылок сервис доставки
Практически все компоненты являются готовыми продуктами.
Преимущество такого подхода — скорость.
Компания может начать работу без собственной команды разработчиков.
Не нужно самостоятельно создавать:
За всё это уже отвечает поставщик сервиса.
Для небольшого бизнеса подобная модель часто рациональна.
Обычно собственная разработка появляется не потому, что компания решила:
Теперь будем писать всё сами.
Она появляется из конкретной проблемы.
Например, компания продаёт сантехнику дилерам.
Готовая CRM подходит для работы менеджеров.
1С подходит для учёта.
Но клиентам нужен кабинет, где они смогут:
У готовой CRM такого интерфейса может не быть.
Тогда компания разрабатывает собственный B2B-портал.
Получается:
CRM — SaaS ERP — готовая B2B-портал — собственный Email — SaaS Телефония — SaaS Интеграция — собственная
Именно такая гибридная архитектура встречается очень часто.
Есть классы программного обеспечения, где собственная разработка обычно имеет мало смысла.
Редкой компании необходимо создавать собственную инфраструктуру электронной почты.
Проще использовать готовый сервис.
Создавать собственный аналог Zoom или Teams ради внутренних встреч обычно экономически нецелесообразно.
Типовые функции уже доступны у специализированных провайдеров.
Здесь важны законодательство, отчётность и постоянные обновления.
Если компании достаточно стандартной модели:
задача → исполнитель → срок → статус
готового продукта обычно хватает.
Отправка писем, отписки, статистика, сегментация и инфраструктура доставки уже хорошо реализованы в специализированных сервисах.
Создавать собственный аналог Google Drive или Dropbox обычно нет необходимости.
Общий принцип:
Чем стандартнее бизнес-задача, тем больше преимуществ у готового продукта.
Собственная разработка чаще появляется в процессах, специфичных для конкретного бизнеса.
Например:
У разных компаний сильно отличаются:
Поэтому стандартный интернет-магазин не всегда подходит.
Например:
дилер → индивидуальная цена → заказ → резерв → документы → доставка
Правила могут сильно зависеть от конкретной компании.
Особенно если товар сложный.
Например:
Если цена определяется десятками параметров, стандартный SaaS может не поддерживать нужную логику.
Например:
Производственные процессы сильно отличаются даже у предприятий одной отрасли.
Например:
У SaaS есть несколько существенных преимуществ.
Регистрация может занимать несколько минут.
Не нужно ждать разработку.
Вместо крупной первоначальной инвестиции компания платит ежемесячную подписку.
Поставщик отвечает за:
В зрелом SaaS могут быть сотни функций, создание которых самостоятельно заняло бы годы.
Не обязательно иметь собственную команду разработчиков.
Поэтому на ранних этапах бизнеса SaaS часто является естественным выбором.
По мере роста бизнеса ситуация меняется.
Компания начинает обнаруживать ограничения.
Например:
Нельзя реализовать нашу систему цен.
Или:
Нельзя изменить процесс согласования заказа.
Или:
Система не умеет работать с несколькими складами так, как нам нужно.
Появляются обходные решения.
CRM ↓ Excel ↓ менеджер ↓ 1С
Сотрудники начинают компенсировать ограничения программы ручной работой.
Именно в этот момент собственная разработка становится экономически интереснее.
Часто развитие выглядит следующим образом.
Excel + email + мессенджер
Количество клиентов небольшое.
Процесс легко контролировать вручную.
Компания внедряет:
Большая часть процессов становится системной.
Появляются интеграции:
сайт ↔ CRM CRM ↔ 1С сайт ↔ оплата CRM ↔ телефония
Компания понимает, что некоторые процессы невозможно удобно встроить в существующие сервисы.
Например:
менеджер всё равно формирует коммерческое предложение вручную.
Не заменяется вся CRM.
Разрабатывается только:
генератор коммерческих предложений
Он получает данные из существующих систем.
В результате:
CRM — SaaS ERP — готовая система телефония — SaaS B2B-портал — собственный расчёт стоимости — собственный интеграция — собственная аналитика — SaaS
Именно такая архитектура часто оказывается наиболее практичной.
Представим, что компания использует CRM, которая решает 90% необходимых задач.
Одна функция работает плохо:
расчёт сложного заказа.
Есть два варианта.
Разработать новую CRM.
Необходимо заново создать:
Оставить CRM и разработать только модуль расчёта.
Чаще второй вариант значительно проще.
Поэтому собственная разработка всё чаще становится дополнением существующего стека, а не его полной заменой.
Допустим, компания продаёт 30 000 товаров.
У неё есть:
1С
товары, цены, остатки.
CRM
работа менеджеров.
B2B-портал
заказы клиентов.
Служба доставки
логистика.
BI
отчётность.
Разрабатывать собственную бухгалтерскую систему нет необходимости.
Но может иметь смысл разработать B2B-портал, потому что именно способ работы дилеров является специфичным для компании.
Получается:
CRM
↑
|
1С ←→ собственный B2B-портал ←→ клиент
|
↓
доставка
Это не выбор между SaaS и custom.
Это комбинация.
Ещё один фактор — модель оплаты.
Многие SaaS тарифицируются:
Представим систему стоимостью:
50 $ / пользователь / месяц
Для пяти сотрудников:
250 $ / месяц
Для 100:
5000 $ / месяц
или:
60 000 $ / год
На определённом масштабе компания может начать сравнивать стоимость подписки со стоимостью собственной разработки.
Но считать нужно не только разработку.
Для собственной системы появляются:
Поэтому формула:
«Разработка стоит 000, а SaaS 000 в год — значит разработка выгоднее»
слишком упрощена.
Нужно сравнивать полную стоимость владения за несколько лет.
Допустим, компании нужно:
выдавать сотрудникам задачи.
Процесс стандартный.
Есть десятки готовых сервисов.
Разрабатывать собственную систему задач обычно нет смысла.
Или требуется:
проводить видеоконференции.
Создание собственного решения будет намного сложнее покупки готового.
Основное правило:
Не стоит разрабатывать то, что не отличается от процессов тысяч других компаний.
Теперь другая задача.
Компания производит мебель.
Заказ проходит этапы:
заявка ↓ замер ↓ проект ↓ согласование ↓ технолог ↓ закупка ↓ производство ↓ монтаж
При изменении размера необходимо автоматически:
Найти SaaS, полностью повторяющий этот процесс, значительно сложнее.
Здесь собственная система уже может иметь смысл.
Компании иногда говорят:
У нас уникальный бизнес, поэтому нам нужна собственная CRM.
Но после анализа оказывается, что процесс продаж совершенно стандартный:
лид → звонок → предложение → договор
В таком случае готовой CRM может быть достаточно.
И наоборот.
Компания может продавать совершенно обычный товар, но использовать сложную модель комплектации.
Тогда конкретный процесс действительно требует разработки.
Поэтому правильный вопрос:
Насколько уникален процесс, который мы пытаемся автоматизировать?
Между готовой системой и полностью собственной существует большое количество промежуточных вариантов.
Например:
Готовый сервис выполняет основные функции, а собственная система работает через API.
Например, CRM остаётся внутренним инструментом менеджеров, а клиент работает через собственный B2B-портал.
Операции между сервисами выполняются автоматически.
Компания берёт готовую платформу и адаптирует её.
Стандартные операции создаются в конструкторе, сложные — программируются отдельно.
Поэтому между «купить» и «разработать» существует целый спектр вариантов.
В 2025–2026 годах появился ещё один фактор — AI-assisted development.
ИИ-инструменты ускоряют:
Это снижает порог создания небольших внутренних систем.
Retool в исследовании 2026 года сообщает, что 51% опрошенных уже создавали с использованием AI production-системы, реально используемые командами. При этом только небольшая часть полностью принимает AI-сгенерированный код без изменений: большинство продолжает проверять и интегрировать его обычными инженерными методами.
Это важное изменение.
Раньше внутренний инструмент:
«таблица заявок + статусы + автоматическое формирование документа»
мог оказаться слишком маленьким проектом для полноценной разработки.
Теперь подобные системы создавать значительно проще.
Поэтому можно ожидать дальнейшего роста количества небольших custom-инструментов вокруг готовых SaaS.
По данным исследования Retool, среди областей, где собственные инструменты начинают заменять SaaS, заметны:
Но это не обязательно означает создание полного аналога Salesforce, Power BI или Jira.
Часто компания заменяет только небольшой фрагмент.
Например:
не:
собственная CRM
а:
собственный интерфейс обработки повторных заказов.
Не:
собственная BI-платформа
а:
собственная панель контроля маржинальности заказов.
Не:
собственная ERP
а:
собственный модуль планирования производства.
Это существенно уменьшает объём разработки.
Представим бизнес-процесс:
Клиент ↓ B2B-портал ↓ CRM ↓ ERP ↓ WMS ↓ Доставка
Совсем не обязательно разрабатывать всю цепочку.
Можно оставить:
CRM — SaaS ERP — готовая WMS — готовая доставка — внешняя
И разработать:
B2B-портал + интеграционный слой
В результате компания сохраняет преимущества готовых продуктов там, где процессы стандартны, и получает гибкость там, где процессы специфичны.
Готовое решение стоит проверить в первую очередь, если:
Например:
Нужна CRM на пять менеджеров.
Сначала логично проверить существующие CRM.
Собственная разработка становится интереснее, если:
Можно задать пять вопросов.
Если да, стоит внимательно рассмотреть SaaS.
Если нет — можно адаптировать процесс.
Если да — появляется аргумент в пользу разработки.
Если сотрудники регулярно используют:
CRM + Excel + Telegram + ручное копирование
проблема уже может быть достаточно серьёзной.
Внутренний корпоративный чат — скорее нет.
Алгоритм расчёта сложного заказа — возможно.
Создать программу недостаточно.
Её необходимо:
Если ответа на этот вопрос нет, SaaS может оказаться безопаснее.
При выборе системы полезно разделить процессы компании на две группы.
Например:
Для них чаще подходит SaaS.
Например:
Здесь чаще появляется смысл собственной разработки.
Получается довольно простой принцип:
Покупать стандартное. Разрабатывать специфичное. Интегрировать всё остальное.
Нельзя корректно сказать, что современный B2B-рынок полностью переходит либо на SaaS, либо на собственное программное обеспечение.
Исследования скорее показывают движение к смешанной модели.
Компании продолжают покупать готовые сервисы для стандартных задач, но одновременно создают собственные инструменты там, где готовое ПО плохо соответствует процессу. Gartner прямо описывает эту модель как сочетание покупки, разработки и интеграции, а исследования 2025–2026 годов показывают заметный интерес компаний к собственным внутренним приложениям.
Поэтому типичная технологическая инфраструктура B2B-компании сегодня может выглядеть так:
CRM → готовая ERP / 1С → готовая email → SaaS телефония → SaaS аналитика → SaaS или гибрид B2B-портал → собственный расчёт заказа → собственный интеграции → собственные внутренние модули → собственные
Главный вопрос поэтому не:
«Что лучше — SaaS или собственная система?»
А:
«Какая часть нашего процесса является стандартной, а какая настолько специфична, что её выгоднее автоматизировать под себя?»
Именно проведение этой границы обычно определяет, какой технологический стек будет рациональным для конкретной B2B-компании.
Нет. Это выборка европейских enterprise-компаний, не малого бизнеса. Паттерн другой: типовое (почта, телефония, бухгалтерия) покупают, специфичный процесс — собирают сами или гибридом.
Когда готовый сервис закрывает 80–90% задачи, а остаток не критичен и не обрастает ежедневными обходами. Если задача решается CMS или конструктором — см. когда Laravel не нужен.
Интервью когда компании нужен свой micro-SaaS — 10 признаков процесса. Здесь — как рынок в целом совмещает покупку и разработку, и почему это не дилемма «или/или».
Чаще нет: оставляют CRM для продаж и выносят специфику в модуль или кабинет. Когда карточка сделки перестаёт вмещать процесс — в материале почему компании отказываются от готовой CRM.
Нужен похожий контур — обсудим. услуги веб-разработки на Laravel.
когда нужен свой micro-SaaS, а не подписка · почему компании отказываются от готовой CRM · как устроен стек B2B · когда Laravel не нужен