CRM под ключ или готовая подписка: как выбрать

Запрос «разработка CRM под ключ» почти никогда не первый шаг — обычно ему предшествует несколько месяцев работы в готовой SaaS-системе, которая на старте казалась достаточной, а потом начала мешать. Процессы бизнеса не укладываются в поля, которые предусмотрел разработчик готового решения; нужный отчёт требует надстройки через сторонний коннектор; за каждого дополнительного пользователя растёт счёт, который никак не связан с тем, сколько реальной пользы система приносит. На этом этапе стоит честно разобраться, где заканчивается «неудобно» и начинается «система физически не может того, что нужно бизнесу».

Когда готовой CRM достаточно

Если процесс продаж стандартный — воронка, звонки, письма, сделки — готовая система вроде популярных SaaS-CRM почти всегда будет быстрее и дешевле, чем разработка с нуля. Она уже прошла путь отладки на тысячах чужих компаний, и переизобретать эту работу ради своего проекта редко оправдано. Сигнал остаться на подписке простой: если единственная жалоба — «интерфейс не такой красивый, как хотелось бы» или «не хватает мелкой функции», это почти всегда решается настройкой или интеграцией, а не переписыванием системы целиком.

Когда это перестаёт работать

Другое дело, когда бизнес-процесс — это и есть продукт, а не вспомогательная функция вокруг продаж. Например, компания ведёт заказы через цепочку статусов, специфичных для её отрасли, которые ни одна готовая CRM не предусматривает из коробки, и обходной путь через кастомные поля и автоматизации выходит настолько запутанным, что его сложнее поддерживать, чем написать систему заново. Или права доступа должны быть тоньше, чем «администратор и обычный пользователь» — нужны роли, специфичные для структуры именно этой компании, с журналом того, кто и когда менял запись. Готовые системы такое тоже умеют, но часто только на дорогих тарифах, где вы платите за десятки функций, которыми никогда не пользуетесь, ради одной, которая нужна.

Как выглядит разница на практике

Ситуация	Готовая CRM	Своя система
Стандартная воронка продаж	Подходит из коробки	Избыточно
Уникальные статусы заказов под отрасль	Обходится через кастомные поля, но хрупко	Отражает процесс напрямую
Тонкие роли и журнал изменений	Часто только на дорогом тарифе	Проектируется под задачу с самого начала
Данные должны остаться внутри компании	Зависит от условий провайдера	Компания владеет кодом и базой полностью

Как мы строим такие системы

Мы не начинаем с кода. Первый шаг — воркшоп по discovery: разбираем текущий процесс, буквально по шагам — кто что делает, какие данные нужны на каждом этапе, что должно попасть в отчёт руководителю. Результат — не абстрактная презентация, а письменная спецификация, которую можно перечитать через месяц и понять, о чём договаривались. Дальше — разработка итерациями: не «вернёмся через полгода с готовым продуктом», а рабочая версия системы каждые две недели, которую можно потрогать и поправить курс, если что-то пошло не туда.

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

Стек — TypeScript и Node.js на бэкенде, PostgreSQL или Cloudflare D1 для хранения данных в зависимости от масштаба, иногда Laravel, если у бизнеса уже есть PHP-экосистема, с которой команде удобнее работать. Выбор конкретной технологии — не вопрос вкуса, а вопрос того, что проще поддерживать именно этой компании через два года.

Что происходит с данными из старой системы

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

Часто новая система должна не заменить старые инструменты полностью, а встать между ними: заявки продолжают приходить через сайт, оплата всё ещё идёт через Stripe, а CRM должна получать эти события автоматически, без ручного переноса данных сотрудником каждое утро. Это уже задача на стыке с интеграциями — если у вас несколько систем, которые должны обмениваться данными между собой в реальном времени, стоит посмотреть отдельно на страницу про интеграции: подход к настройке связи между системами там во многом такой же, как при построении CRM с нуля.

Как это оплачивается

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

Кому принадлежит результат

Здесь принципиальная разница с подпиской: в готовой CRM данные и логика живут на серверах провайдера, а вы платите за доступ. В системе, которую мы строим, заказчик получает полный исходный код, репозиторий и документацию — причём не в конце проекта одним архивом, а на каждой контрольной точке по ходу работы. Это значит, что если через три года потребуется другая команда для доработки, ей не придётся начинать с нуля или разбирать код без единого комментария.

Правило, которым мы пользуемся

Мы не советуем клиенту разработку с нуля, если проблему решает более дешёвая настройка готовой системы — даже если проект под ключ был бы для нас выгоднее. И наоборот: не советуем оставаться на подписке, если процесс компании реально не помещается в чужую систему, а обходные пути уже стали дороже, чем прямое решение.

Если сомневаетесь, в какую сторону смотреть, — расскажите нам о процессе, а мы скажем честно, что из этого разумнее в вашем случае. Подробнее о том, как мы строим такие системы, — на странице custom software, а весь список того, чем занимается студия, — на странице услуг.