Сколько стоит разработка CRM с нуля: считаем не экраны, а сложность системы

С CRM та же история.

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

Поэтому стоимость CRM правильнее считать не по количеству страниц интерфейса, а по сложности бизнес-процессов, которые система должна взять на себя.

Разберём, из чего на самом деле складывается цена разработки CRM с нуля, какие функции оказываются самыми дорогими и как ещё до начала программирования понять порядок будущего бюджета.

Сначала определимся: что значит «CRM с нуля»

Под CRM часто понимают совершенно разные системы.

Для одной компании достаточно базы клиентов, сделок, задач и нескольких отчётов. Для другой CRM должна автоматически принимать заявки с сайта, распределять их между менеджерами, синхронизироваться с телефонией, отправлять документы, считать показатели сотрудников и передавать данные в бухгалтерию.

А иногда под словом CRM фактически скрывается внутренняя ERP-система.

Например, бизнес хочет видеть:

клиента → заявку → расчёт → договор → оплату → производство → доставку → закрывающие документы.

Формально это можно назвать CRM. Технически же разработчик получает систему управления значительной частью компании.

Именно здесь возникают первые ошибки в оценке.

Заказчик представляет десять экранов интерфейса. Разработчик видит десятки состояний объектов, переходы между ними, права пользователей, фоновые процессы, API, журналирование, файловое хранилище, уведомления и обработку ошибок.

Поэтому хороший расчёт начинается не с макетов.

Он начинается с процессов.

Цена CRM — это стоимость автоматизации процессов

Для предварительного расчёта удобно представить стоимость проекта в виде простой модели:

Стоимость CRM = аналитика + проектирование + интерфейс + backend + frontend + интеграции + тестирование + инфраструктура + управление разработкой + резерв на неопределённость.

Последняя составляющая особенно важна.

В начале проекта невозможно знать абсолютно всё.

Выясняется, что клиент может относиться одновременно к нескольким направлениям бизнеса. Сделка должна иметь дополнительные статусы. Руководителю нужен отдельный уровень доступа. Документы должны формироваться автоматически. У старой системы оказывается нестандартный формат выгрузки.

Если архитектура CRM позволяет спокойно добавлять такие изменения — проект развивается нормально.

Если система проектировалась только под первоначальные макеты, каждое изменение начинает ломать соседние модули.

Именно поэтому две CRM с одинаковым количеством экранов могут отличаться по стоимости разработки в несколько раз.

Попробуем посчитать CRM в часах

Вместо абстрактного «дорого или дёшево» рассмотрим три условных проекта.

Это не прайс-лист рынка, а расчётные сценарии, позволяющие понять порядок трудозатрат.

Теперь можно подставить стоимость часа конкретной команды.

Допустим, для математического примера используется усреднённая ставка команды 3000 рублей за час.

CRM на 800 часов будет означать примерно 2,4 млн рублей разработки.

Проект на 1800 часов — около 5,4 млн.

Система на 4000 часов — около 12 млн.

При ставке 2000 рублей цифры будут другими. При 5000 рублей — тоже.

Но гораздо важнее другое: трудоёмкость проекта обычно влияет на бюджет сильнее, чем сама ставка разработчика.

Попытка уменьшить стоимость часа на 20% мало поможет, если из-за плохо продуманной архитектуры проект потребует на 50% больше разработки.

Откуда вообще берутся тысячи часов

Представим CRM для компании, где работают менеджеры и руководители.

Нужно хранить клиентов и контакты, вести сделки по воронке, назначать задачи, оставлять комментарии, прикладывать документы, получать уведомления, разграничивать доступ сотрудников, строить отчёты и интегрироваться с несколькими внешними сервисами.

Первоначально всё это может выглядеть как несколько разделов меню.

На практике примерная декомпозиция проекта может оказаться такой:

Даже такой расчёт ещё не означает, что проект можно оценить ровно в 1510 часов.

Разумно оставить резерв на изменение требований и технические неизвестные.

Например, при резерве 15% получаем около 1740 часов.

При той же условной ставке 3000 рублей получается примерно 5,2 млн рублей.

И вот здесь становится понятно, почему вопрос «Сколько стоит CRM?» без описания системы почти не имеет смысла.

Самая дорогая часть CRM часто вообще не видна пользователю

Представим простой интерфейс:

Статус сделки: «Согласование договора».

Для пользователя это одно поле.

Но за ним может стоять следующий процесс.

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

В интерфейсе по-прежнему отображается один статус.

Но технически это уже полноценный автоматизированный процесс.

Поэтому оценка CRM по количеству кнопок или страниц практически всегда ошибочна.

Права доступа могут оказаться сложнее самих функций

На старте часто формулируют просто:

«Есть администратор, руководитель и менеджер».

Через некоторое время появляются подробности.

Менеджер должен видеть только своих клиентов.

Руководитель отдела — клиентов всех сотрудников своего отдела.

Региональный руководитель — несколько отделов.

Некоторые финансовые показатели должны быть скрыты от менеджеров.

Сотрудник бухгалтерии должен видеть договоры и платежи, но не внутренние комментарии отдела продаж.

Уволенного сотрудника нужно заблокировать, сохранив все совершённые им действия.

Администратор не должен иметь возможность незаметно изменить историю сделки.

В результате обычная проверка:

role === "manager"

превращается в полноценную модель авторизации.

Появляются роли, разрешения, группы, подразделения, принадлежность объектов, наследование доступа и аудит действий.

Если такие требования обнаруживаются после разработки половины системы, изменение модели доступа может затронуть практически каждый модуль.

Поэтому проектирование authorization-модели нужно проводить ещё до активной разработки CRM.

Интеграция — это не просто один API-запрос

Интеграции часто сильно недооценивают.

На схеме всё выглядит красиво:

CRM → API → внешний сервис.

Но реальная интеграция должна учитывать значительно больше сценариев.

Что произойдёт, если внешний сервис временно недоступен?

Нужно ли повторить запрос через минуту?

А через десять минут?

Что делать, если запрос выполнился, но ответ потерялся?

Как избежать двойного создания платежа или заказа?

Как понять, какие данные являются актуальными, если пользователь изменил объект одновременно в двух системах?

Как обрабатывать изменение API внешнего сервиса?

Как администратор узнает, что синхронизация не работает уже несколько часов?

После таких вопросов появляется очередь фоновых задач, механизм повторных попыток, idempotency, журнал интеграций, система мониторинга и интерфейс для разбора ошибок.

Именно поэтому фраза «нужно просто подключить API» может означать как несколько часов работы, так и отдельный подсистемный проект.

Отчёты тоже бывают очень разными

Запрос «нам нужна аналитика» практически ничего не говорит о сложности.

Простой отчёт может представлять собой SQL-запрос с группировкой данных по месяцам.

Но руководителю может понадобиться совершенно другое:

конверсия воронки за выбранный период, среднее время нахождения сделки на каждом этапе, эффективность сотрудников, повторные продажи, причины отказов, прогноз выручки, сравнение отделов и динамика показателей относительно предыдущего периода.

Добавим фильтры, экспорт в Excel, разграничение доступа и большие объёмы данных.

Теперь это уже отдельный аналитический модуль.

А если показатели должны рассчитываться практически в реальном времени на миллионах записей, может потребоваться дополнительная архитектура для агрегирования данных.

«У нас будет всего двадцать пользователей» не всегда означает простую CRM

Нагрузка — только один из факторов сложности.

CRM для двадцати сотрудников может быть технически значительно сложнее системы для нескольких тысяч пользователей.

Например, небольшой производственной компании может потребоваться сложный жизненный цикл заказа:

заявка → замер → расчёт → коммерческое предложение → договор → предоплата → производство → контроль качества → доставка → монтаж → окончательная оплата.

У каждого этапа свои ответственные сотрудники, документы, сроки, зависимости и правила перехода.

Пользователей немного.

Но количество бизнес-правил огромное.

Поэтому число аккаунтов почти никогда нельзя использовать как главный показатель стоимости разработки.

Что сильнее всего увеличивает бюджет

Один дополнительный справочник обычно почти не влияет на стоимость проекта.

Совсем другая ситуация возникает, когда добавляются сложные взаимосвязи между сущностями.

Представим, что клиент может иметь несколько компаний, каждая компания — несколько договоров, договор связан с проектами, проекты — со сделками, сделки — с платежами и документами, а доступ зависит одновременно от подразделения, проекта и роли сотрудника.

Количество таблиц базы данных само по себе не проблема.

Проблемой становится количество правил.

Чем больше условий вида:

«если A, но только когда B, кроме случая C, а пользователь с ролью D может делать это только для объектов подразделения E», —

тем дороже система в разработке и дальнейшем сопровождении.

Почему дешёвая CRM иногда оказывается самой дорогой

Есть два способа создать первую версию системы.

Первый — разработать минимальный объём функций, но сразу определить границы модулей, модель данных, принципы авторизации, миграции базы, API и подход к тестированию.

Второй — максимально быстро соединить необходимые экраны так, чтобы система начала работать.

Первый вариант может потребовать больше времени в начале.

Второй часто выглядит дешевле.

Проблемы появляются позже.

Компания просит добавить второй отдел — существующая модель прав этого не позволяет.

Появляется новая воронка — статусы оказались жёстко прописаны в коде.

Нужно добавить автоматизацию — события системы нигде не фиксируются.

Потребовалась интеграция — у приложения нет нормального API.

Нужно понять, кто изменил сумму сделки, — журналирования действий нет.

После нескольких таких изменений команда уже не расширяет систему, а постоянно обходит ограничения старой архитектуры.

Технический долг начинает превращаться в финансовый.

Значит ли это, что CRM нужно сразу проектировать «на десять лет вперёд»?

Нет.

Избыточная архитектура тоже стоит денег.

Нет смысла создавать микросервисную платформу для CRM, которой пользуются десять сотрудников и которая выполняет несколько стабильных процессов.

Часто оптимальным вариантом для первой версии оказывается хорошо структурированный модульный монолит.

Например:

CRM
│
├── Auth
├── Users & Permissions
├── Customers
├── Deals
├── Tasks
├── Documents
├── Notifications
├── Reports
└── Integrations

Физически это может быть одно приложение и одна основная база данных.

Но логически ответственность уже разделена.

Если проект вырастет, отдельные компоненты можно масштабировать или выносить постепенно.

Это значительно дешевле, чем преждевременно строить распределённую систему, и безопаснее, чем складывать весь бизнес-код в один неструктурированный модуль.

PostgreSQL, Redis, очереди — что действительно нужно CRM

Для большинства CRM реляционная база данных остаётся естественным выбором.

Клиенты связаны со сделками, сделки с задачами, пользователями, платежами и документами. Для таких данных важны связи, ограничения и транзакции.

Например, PostgreSQL хорошо подходит для основной операционной модели.

Redis может использоваться для кэширования, временных данных или механизмов очередей, но добавлять его только потому, что «так современнее», смысла нет.

Отдельная очередь становится полезной, когда появляются фоновые операции.

Например:

Менеджер переводит сделку в новый статус
                ↓
CRM фиксирует изменение
                ↓
Создаёт фоновую задачу
                ↓
Формируется документ
                ↓
Отправляется уведомление
                ↓
Данные передаются во внешнюю систему

Пользователь при этом не должен ждать завершения всех внешних операций.

Такой подход улучшает устойчивость системы, но также увеличивает объём разработки.

И это ещё один пример функции, которая практически не заметна на макете интерфейса, но влияет на стоимость CRM.

Не забудьте про историю изменений

Для бизнес-систем возможность ответить на вопрос «кто и когда это изменил?» часто важнее красивой анимации интерфейса.

Минимальный аудит может хранить:

2026-09-18 10:42
Пользователь: Иван Петров
Сделка: #4821
Поле: сумма
Было: 480 000
Стало: 520 000

Но журнал изменений нужно не просто записать.

Нужно решить, какие действия отслеживаются, кто имеет доступ к журналу, как долго хранятся записи и можно ли изменить их административным способом.

Если CRM связана с финансовыми или юридически значимыми процессами, требования становятся ещё серьёзнее.

А сколько должна стоить первая версия?

Вместо разработки всей задуманной CRM разумнее определить первый рабочий контур.

Не демонстрационный прототип, а минимальную систему, которая полностью закрывает один или несколько реальных процессов компании.

Например:

заявка → клиент → сделка → задача менеджеру → изменение статусов → результат.

Без двадцати отчётов.

Без сложного конструктора автоматизаций.

Без второстепенных интеграций.

Но с нормальной моделью данных, авторизацией, резервным копированием и архитектурой, которую можно развивать.

Так бизнес быстрее получает рабочий инструмент, а команда проверяет архитектурные решения на реальных пользователях.

После этого развитие CRM происходит итерациями.

Когда собственную CRM вообще не стоит разрабатывать

Разработка с нуля — не универсальное решение.

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

Готовое решение особенно логично, когда процессы стандартны, требуется быстрое внедрение и компания готова адаптировать работу под возможности платформы.

Своя разработка становится интереснее, когда программное обеспечение должно адаптироваться под бизнес, а не наоборот.

Например, когда компания имеет нестандартные процессы, большое количество внутренней автоматизации, специфические правила расчётов, собственные клиентские кабинеты, сложные интеграции или CRM фактически является частью продукта компании.

Есть и промежуточный вариант: готовая система плюс собственные модули и интеграции.

Поэтому перед началом разработки полезно сначала доказать, что индивидуальная CRM действительно нужна.

Как получить нормальную оценку до написания огромного ТЗ

Для первой оценки не обязательно описывать каждую кнопку.

Гораздо полезнее зафиксировать процессы.

Вместо:

Сделать страницу клиентов.

лучше написать:

Менеджер получает заявку с сайта. Если клиента ещё нет в базе, CRM создаёт его автоматически. Клиент закрепляется за менеджером. Руководитель может изменить ответственного. Все предыдущие назначения должны сохраняться в истории.

Такое описание уже позволяет разработчику увидеть несколько сущностей и правил.

Чем лучше описаны реальные сценарии работы, тем точнее получится предварительная оценка.

После этого сценарии декомпозируются на модули, выявляются интеграции и технические риски, определяется архитектура и только затем рассчитываются трудозатраты.

Что должно появиться до начала основной разработки

Хороший этап проектирования заканчивается не фразой «вроде всё понятно».

У команды должна появиться модель системы.

Например:

Пользователь
      │
      ├── принадлежит отделу
      │
      └── имеет набор разрешений

Клиент
      │
      ├── имеет контакты
      ├── связан со сделками
      └── содержит историю взаимодействий

Сделка
      │
      ├── находится в воронке
      ├── имеет ответственного
      ├── содержит задачи
      ├── содержит документы
      └── генерирует события

Должно быть понятно, где проходит граница каждого модуля, каким образом проверяются права, какие процессы выполняются синхронно, какие уходят в фон и какие данные передаются внешним системам.

После этого оценка перестаёт быть гаданием.

Как уменьшить стоимость CRM, не превращая её в одноразовый прототип

Главный способ экономии — не поиск самой дешёвой технологии.

Главный способ — сокращение ненужной сложности.

Предположим, бизнес хочет собственный конструктор отчётов.

Его разработка может занять сотни часов.

Но если на первом этапе реально используются пять фиксированных отчётов, гораздо разумнее реализовать именно их.

То же относится к визуальному конструктору бизнес-процессов, сложной кастомизации интерфейса, поддержке десятков ролей, универсальному API и другим «возможностям на будущее».

Хорошая архитектура не означает, что нужно заранее разработать всё.

Она означает, что сегодняшние решения не должны блокировать завтрашнее развитие.

Что происходит со стоимостью после запуска

Запуск CRM — не конец разработки.

После появления реальных пользователей почти всегда обнаруживаются новые требования.

Меняются процессы.

Появляются новые отчёты.

Подключаются внешние сервисы.

Изменяются API интеграций.

Накапливаются данные.

Появляются требования к производительности.

Кроме развития системы существуют резервное копирование, обновление зависимостей, мониторинг, работа с логами, восстановление после сбоев и проверка безопасности.

Поэтому при расчёте экономики собственной CRM нужно учитывать не только стоимость первоначального проекта, но и стоимость владения системой.

Почему нельзя назвать точную цену за пятнадцать минут

Если после короткого разговора исполнитель называет точную стоимость сложной CRM, возможны два варианта.

Либо он заранее заложил большой запас.

Либо значительная часть требований пока просто не попала в оценку.

Адекватный предварительный расчёт может выглядеть как диапазон.

Например:

1400–1800 часов.

А рядом должны находиться предположения, на которых он основан.

Так заказчик понимает не только цифру, но и причины её изменения.

После аналитики диапазон постепенно сужается.

Это значительно полезнее иллюзии точности вроде:

«Проект стоит 3 847 000 рублей»

до того, как подробно изучены процессы компании.

Пример: как один вопрос меняет стоимость проекта

Представим, что нужно добавить документы к сделкам.

Первая версия требования:

Пользователь может прикрепить файл.

Это относительно простая функция.

Теперь меняем условие:

Документ формируется по шаблону на основании данных сделки, имеет несколько версий, проходит согласование двух сотрудников, подписывается, отправляется клиенту, а CRM должна хранить историю всех изменений.

В интерфейсе по-прежнему находится раздел «Документы».

Технически же появился самостоятельный workflow.

Именно такие детали определяют настоящий бюджет CRM.

Так сколько всё-таки стоит CRM с нуля?

Если нужна ориентировочная модель, можно использовать такую шкалу.

После этого объём умножается на эффективную стоимость часа команды.

Но этот расчёт имеет смысл только после того, как определены основные процессы.

Поэтому правильный вопрос звучит не:

«Сколько стоит CRM?»

а:

«Какие бизнес-процессы мы хотим перенести в систему и какая сложность за ними скрывается?»

Ответ на него и определяет настоящий бюджет.

Вместо вывода

Стоимость разработки CRM с нуля определяется не количеством экранов, красивыми макетами и даже не количеством пользователей.

Главный фактор — сложность правил, которые система должна выполнять вместо людей.

Если CRM просто хранит клиентов и сделки, объём разработки может быть относительно небольшим.

Если она распределяет ответственность между отделами, управляет документами, синхронизирует внешние сервисы, контролирует процессы, считает показатели и фиксирует каждое значимое действие, речь идёт уже о полноценной информационной системе.

И именно поэтому качественная оценка начинается не с вопроса о технологиях.

Она начинается с разбора бизнеса.

Сначала нужно понять процессы.

Затем определить данные и связи.

После этого — права пользователей и автоматизацию.

Затем интеграции.

И только потом архитектуру, трудоёмкость и стоимость.

Так вместо случайной цифры появляется оценка, которую можно объяснить, проверить и использовать для принятия решения.