Подписку на готовый сервис сравнивают со сметой на разработку — и на этом сравнении разговор обычно заканчивается, потому что подписка дешевле в сто раз. Сравнение при этом неверное: в одной колонке стоит месяц, в другой — продукт, который проживёт несколько лет.
Мы в Code Pilots строим и то и другое: делаем SaaS-платформы для клиентов и сами платим за десяток чужих подписок. Поэтому разберу способ считать, при котором решение держится дольше квартала. SaaS или своя разработка — вопрос арифметики на горизонте трёх лет и нескольких рисков, которые в прайс не попадают.

Не цену входа, а стоимость владения на три года. Три года — потому что за этот срок разработка успевает окупиться, а подписка успевает подорожать.
В колонку подписки складывается всё, что уйдёт поставщику: тариф за пользователей, доплата за модули и лимиты, доработки под вас, часы интеграции с вашими системами и работа людей, которые обслуживают неудобные места сервиса руками.
В колонку своего решения — разработка первой версии, инфраструктура, поддержка и развитие, а также время ваших сотрудников на приёмку и внедрение. Считать нужно все три года, включая те, где ничего не запускают: продукт без развития стареет так же, как чужой сервис.
Дальше остаётся сравнить две суммы и посмотреть, в какой момент линии пересекаются. Если пересечение приходится на четвёртый год, берите подписку. Если на второй — считайте всерьёз.
Тариф со страницы поставщика — это начало списка.
Пользователи. Цена за место умножается на рост компании. Модель, комфортная на десяти сотрудниках, на сотне выглядит иначе, и решение о найме внезапно начинает зависеть от стоимости лицензии.
Модули и лимиты. Нужная функция часто живёт в старшем тарифе вместе с десятком ненужных. То же с объёмами: письма, хранилище, запросы к интерфейсу.
Доработки через вендора. Это самая недооценённая строка. Вам нужно небольшое изменение — оно уходит в очередь поставщика, где стоит в одном ряду с запросами всех остальных клиентов. Сроки вы не контролируете, а иногда получаете отказ: функция не вписывается в его продукт.
Интеграции. Обмен с учётной системой, с сайтом, с кабинетом клиента пишется всё равно, и его стоимость от модели не зависит.
Ручной труд вокруг. Сервис закрывает восемьдесят процентов процесса, оставшиеся двадцать сотрудники делают в таблицах. Эти часы — тоже часть счёта, просто они не приходят в виде инвойса.

Четыре ситуации, и в каждой дело не в размере компании.
Процесс не типовой. Если ваша работа отличается от того, подо что сделан сервис, вы платите дважды: за подписку и за обходные пути. Чем дальше процесс от шаблона, тем быстрее приходит переход.
Продукт — это и есть бизнес. Когда через систему идут деньги и клиенты, зависимость от чужой дорожной карты становится риском. Блогер Анастасия Миронова продавала курсы через соцсети и мессенджеры: аудитория есть, а воронка чужая, оплаты нет, аналитики нет, часть заказов теряется. Мы собрали ей продукт — приложение онлайн-школы с тренировками, питанием, подписками и встроенной оплатой. Здесь своя разработка была не про экономию. Она была про то, кому принадлежит канал продаж.
Много пользователей. Плата за место линейна, разработка — нет. На какой-то численности подписка обгоняет стоимость собственного решения и дальше растёт вместе со штатом.
Данные нужны вам целиком. Аналитика, обучение моделей, объединение с другими источниками — всё это требует доступа к сырым данным. У чужого сервиса вы получаете тот срез, который он готов отдать.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Честная часть разговора, без которой предыдущий раздел выглядит агитацией.
Собственный продукт нужно содержать. Серверы и мониторинг, обновления библиотек и безопасность, поддержка пользователей, развитие под новые задачи — это постоянная статья расходов. Плюс зависимость от команды: если продукт делал подрядчик, вам нужны переданные исходники, документация и доступы, иначе вместо вендора у вас появится другой вендор.
Есть и риск сроков. Подписку включают сегодня, продукт выходит через месяцы. Если задача горит, правильный ход — начать с подписки и переехать позже, когда станет понятно, что именно вам нужно. Требования к своей системе, написанные после года работы в чужой, получаются гораздо точнее.
Первый — изменение цены. Тариф пересматривают, бесплатный план закрывают, функцию переносят в старший пакет. Поставщик в своём праве, а у вас внутри уже выстроены процессы.
Второй — уход поставщика. Он может уйти с рынка, сменить владельца или закрыть направление. Вопрос «что мы делаем в этот день» стоит задать себе до подписания. После письма о прекращении обслуживания отвечать на него поздно.
Третий — данные. Выгрузка есть почти везде, но в формате поставщика и не всегда полная. Проверять её нужно в первый месяц работы, а не в момент расставания: один раз выгрузить всё и посмотреть, что получилось.
Практический вывод: в договоре важны не только цена и функции, но и условия выхода. Это дешёвая страховка, которую почти никто не оформляет.
Подписка и своя разработка — не взаимоисключающие вещи, и в жизни они обычно сочетаются.
Типовые задачи остаются в готовых сервисах: почта, документы, бухгалтерия, таск-трекер. Там, где процесс уникален и приносит деньги, строится своё — и стыкуется с остальным через обмен данными. Так компания платит за стандарт как все и вкладывается только в то, что отличает её от конкурентов.
Этот же подход работает и в обратную сторону. Если вы сами делаете продукт по подписке, чужие сервисы внутри него — нормальная практика: платежи, рассылки, хранилище. Строить всё самому дороже и медленнее, чем кажется. Как устроена модель подписки изнутри и что нужно, чтобы запустить свой сервис, мы разобрали в отдельном материале.
Три шага, каждый занимает день-два.
Первый: опишите процесс как он есть, с обходными путями и таблицами. Именно в них видно, где готовый сервис не справляется.
Второй: сложите обе колонки на три года. Не по памяти, а по счетам: выгрузите платежи поставщику за прошлый год и добавьте то, что платите людям за ручную работу вокруг сервиса.
Третий: проверьте выход. Запросите полную выгрузку данных и посмотрите, что в ней есть. Этот шаг стоит ноль рублей и меняет решение чаще остальных.
Если после этого пересечение линий попадает на второй год, считайте разработку своего решения предметно: с оценкой по задачам и планом перехода. Мы в таких случаях обычно предлагаем начинать с отдельного сервиса рядом, который закрывает самую дорогую часть процесса и работает вместе с подпиской.
Что дешевле: SaaS или своя разработка? На горизонте года почти всегда подписка. На горизонте трёх лет всё решают число пользователей, объём доработок и ручная работа вокруг сервиса. Считайте стоимость владения на три года; цена входа тут мало что значит.
Когда стоит делать свою систему? Когда процесс не совпадает с логикой готового сервиса, когда система приносит деньги и зависеть от чужой дорожной карты рискованно, когда пользователей много и плата за места растёт быстрее бизнеса или когда нужны сырые данные.
Что будет, если поставщик закроется? Зависит от того, что вы успели забрать. Поэтому полную выгрузку данных проверяют в первый месяц работы, а условия выхода закрепляют в договоре наравне с ценой.
Можно ли начать с SaaS и перейти на своё? Это самый частый и самый разумный путь. Год работы в готовом сервисе даёт точные требования к собственному решению — и заодно показывает, нужно ли оно вообще.
Обязательно ли заменять всё сразу? Нет. Обычно выносят одну самую дорогую часть процесса и стыкуют её с подпиской через обмен данными. Остальное переносят по мере необходимости, а иногда не переносят вовсе.