Заказная разработка или готовое решение в 2026 году

По умолчанию — готовое решение. Если ваши процессы типовые (продажи, задачи, документы, база клиентов, права доступа), в коробке они уже описаны, обкатаны на массовом рынке и обновляются без вашего участия. Разработка нужна там, где эта презумпция не срабатывает, а не там, где просто хочется «своё, сделанное под нас».

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

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

Сравнивать имеет смысл не по функциям, а по тому, как решение ведёт себя на дистанции: что происходит через год, когда закончится проект и начнётся эксплуатация. Функции догоняются, а вот стоимость владения и ответ на вопрос «кто это чинит в субботу» заданы выбором с самого начала.

Стоимость входа в коробку видна публично и её можно проверить до разговора с подрядчиком. Ниже — официальные облачные тарифы Битрикс24 при оплате за год: Бесплатный — 0 ₽ с базовыми функциями, Базовый на 5 пользователей — 1 743 ₽/мес, Стандартный на 50 пользователей — 4 893 ₽/мес, Профессиональный на 100 пользователей — 9 793 ₽/мес, Энтерпрайз от 250 пользователей — от 23 793 ₽/мес. Это цена платформы; работы по внедрению считаются отдельно.

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

Развилка «коробка или своя разработка» ложная чаще, чем кажется. Есть третий вариант: готовая платформа остаётся фундаментом — там живут клиенты, сделки, задачи, сотрудники и права, — а поверх неё разрабатываются только те части, которых в платформе нет. Вы не пишете CRM заново, вы дописываете недостающие узлы, а основную часть системы продолжает поддерживать вендор платформы.

Как это выглядит на практике — кейс сети из 5 банных комплексов в Санкт-Петербурге (клиент анонимен). База — коробочный Bitrix24. Сверху построено то, чего в коробке не существует: «шахматка» бронирования кабинок как внутреннее приложение Bitrix24 с собственной базой, где администратор видит занятость по всем комплексам. К ней подключён портал сотрудника с ролями админа, администратора бани, специалиста и официанта. Заказы кафе идут через POS-кассу, которая работает через Bitrix24 REST, а не как отдельная касса со своей базой.

Ключевое здесь — не список функций, а то, где лежат данные. Касса и портал не заводят параллельный учёт: они обращаются к платформе через её API, поэтому клиент, оплата и сотрудник остаются одной записью, а не тремя копиями в трёх системах. Туда же встроена механика лояльности, выпуск сертификатов и абонементов. Стек надстройки — Node.js, Fastify, PostgreSQL, Redis и React; сам проект вырос из уже идущего сопровождения портала, а не начинался с чистого листа.

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

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

Масштаб такой предметной области хорошо виден на нашем собственном продукте — МИС, медицинской информационной системе. Прежде чем писать код, мы разобрали работающий аналог: 1613 таблиц базы данных и 1029 роботов (автоматических сценариев, которые срабатывают по событию, например «записали пациента — создали напоминание»). По итогам разбора собрано техническое задание на воспроизведение из 1619 требований. Это не «CRM для клиники с кастомными полями» — это отдельная предметная область, которую в чужую модель данных не уложить.

Честно про статус: МИС сейчас на стадии MVP, а не готового релиза. В минимально работающей версии есть расписание регистратуры, медкарта врача с зубной формулой и дашборд управляющего; остальное из 1619 требований — план, а не факт. Мы называем это ровно так, потому что разница между MVP и продом здесь принципиальна для того, кто выбирает систему для клиники.

Второй признак сломанной коробки — требования к данным, которые нельзя выполнить настройками. В МИС мультиарендность (несколько клиник или филиалов в одной системе) сделана через RLS в PostgreSQL — это разграничение на уровне самой базы данных. Чужие строки не отдаются приложению в принципе, а не отфильтровываются условием в коде: даже ошибка в запросе не покажет одной клинике данные другой.

Туда же относится контур 152-ФЗ: согласия на обработку, журнал доступа к персональным данным и сроки хранения заложены в архитектуру, а не добавлены косметикой перед проверкой. Если ваши требования к данным звучат так же — это уже разработка отраслевой системы, и решать её настройкой готового продукта не получится.

Больше, чем стоит его написать, — и это главная строка, которую забывают в расчётах. Разработка заканчивается, а владение начинается: систему нужно держать в живом состоянии, развивать под изменения бизнеса и закона, объяснять новым сотрудникам и чинить, когда что-то ломается. У коробки эта работа входит в подписку и делится между всеми клиентами вендора. У своего решения её оплачиваете только вы.

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

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

Мы закрываем этот риск явно: после релиза сопровождаем и развиваем решение, а передачу исходников, документации и доступов фиксируем в договоре. Это не отменяет расходов на владение — это делает их предсказуемыми и позволяет сменить команду, не переписывая систему заново.

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

Аргумент «нам нужны свои поля и своя воронка» разработку не оправдывает: поля, стадии, права, автоматизации и отчёты настраиваются в готовых системах. Аргумент «нам важно, чтобы данные лежали у нас» тоже решается без разработки — коробочные версии ставятся на ваш сервер, а есть ещё self-hosted-продукты вроде EspoCRM.

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

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

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

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

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

Мы делаем и внедрение готовых продуктов, и заказную разработку — порталы, личные кабинеты, интеграции, POS, — и связываем разработанное с Битрикс24, CRM и учётными системами через API, чтобы данные не переносили руками. Поэтому нам нет смысла продавать вам разработку там, где хватит настройки: заработок в обоих сценариях, а репутация — только в честном ответе.

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