- Нам нужен просто сайт на Битриксе.
- Просто сайт - это что именно?
- Каталог, личный кабинет, остатки из 1С, цены по дилерам, заявки в CRM.
- Тогда у вас сайт - уже часть внутренней системы, а не отдельная витрина.
Я регулярно вижу одну и ту же ошибку: платформу выбирают по рыночной привычке, хотя у бизнеса задача совсем другая. Ниже - не теория, а признаки, по которым я обычно понимаю, в каких случаях Битрикс экономит команде время, а в каких добавляет лишние недели, сложность и дорогие изменения через год.
Битрикс окупается там, где сайт связан с учетом и продажами
Если упростить, Битрикс приносит максимум пользы там, где сайт держит на себе бизнес-правила. Остатки приходят из 1С, у дилеров свои цены, менеджеры работают с отдельными группами клиентов, заявки уходят в CRM, контент редактируют несколько сотрудников с разными правами. В такой конфигурации важна уже не витрина сама по себе, а предсказуемая работа данных, ролей и обменов.
У нас был проект для дистрибьютора инженерного оборудования. Каталог - 18 000 SKU, 4 типа цен, обмен с 1С по остаткам и заказам, роли для дилеров и менеджеров. Собирали на 1С-Битрикс: Управление сайтом, редакция Бизнес, с PHP 8.3, MySQL 8, композитом для ускорения каталога и Redis для сессий под нагрузкой кабинета. До запуска сотрудники вручную правили наличие и цены, поэтому в заказах постоянно возникали расхождения. После запуска ручных правок по наличию и ценам стало меньше примерно на 60%, а число заказов с расхождениями по цене или остатку снизилось на 31% за 3 месяца.
Большой каталог сам по себе еще ничего не доказывает. Битрикс имеет смысл там, где в ежедневной работе уже есть много правил, ролей и обменов.
Для быстрого MVP и нетипового продукта Битрикс чаще мешает
Для лендинга, промо-сайта, медиа или сервиса, где продукт меняется каждую неделю, тяжелая CMS обычно не окупается. Здесь задача другая: выйти в релиз за 4-6 недель, быстро проверять спрос, без лишних потерь менять структуру и не платить за обход ограничений платформы.
У нас был неудачный старт с сервисом по подписке. Сначала мы пошли через Битрикс, потому что решили, что знакомая CMS снизит риск. Через 3 недели стало понятно по двум признакам: стандартные сущности почти не участвуют в продукте, а подписка, биллинг, продление доступа и ограничения по ролям все равно уходят в кастомную бизнес-логику. Работу остановили и пересобрали систему на Node.js 20 + NestJS, фронтенд сделали на Next.js 15, базу - на PostgreSQL 16. Первый рабочий релиз вышел на 7 недель раньше обновленного плана на Битриксе, а бюджет сократился примерно на 28%.
Худший сценарий я видел не раз: Битрикс берут «на вырост», а через полгода половину ядра проекта команда просто обходит своим кодом. Когда больше 50% функций приходится ломать под нетиповой сценарий, CMS выбрана не под эту задачу.
Ошибка часто начинается с путаницы между разными продуктами
На встречах это обычно звучит почти дословно:
- Нам нужен сайт на Битрикс CRM.
- Что уже куплено?
- Битрикс24.
- Тогда движка сайта у вас пока нет.
Путаница с продуктами съедает время еще до старта. У клиента из оптовой торговли мы потеряли почти 2 недели на обсуждение интеграций и ролей, хотя базовую платформу сайта никто толком не определил.
| Продукт | Для чего нужен | Что не заменяет |
|---|---|---|
| 1С-Битрикс: Управление сайтом | сайт, каталог, заказы, пользователи | CRM |
| Битрикс24 | продажи, задачи, процессы, коммуникации | движок сайта |
| Битрикс CRM | CRM-функции внутри Битрикс24 | отдельный сайт |
Ошибка здесь простая: покупают Битрикс24 и считают, что сайт уже «почти готов». На практике сначала нужно описать, где живут данные, куда уходят заявки и кто чем управляет. После этого обычно быстро становится ясно, где нужен сайт, где CRM, а где достаточно обычной интеграции по API.
Проект дорожает не лицензией, а тем, как собраны каталог, обмен и кабинет
Лицензия заметна в смете, поэтому на нее смотрят первой. Но в реальном проекте ее доля нередко меньше 10% стартового бюджета. Основные деньги уходят в каталог, обмен с 1С, оплату, доставку, права доступа, доработки кабинета и поддержку после запуска.
Платформу я обычно оцениваю по пяти вещам:
- сколько стоит запуск;
- сколько стоят изменения через 12-24 месяца;
- что ломается после обновлений;
- насколько проект зависит от внешних модулей;
- сколько ручной работы остается у контента и продаж.
На поддержку сильнее всего влияют вещи, которые на старте кажутся скучными: как собраны инфоблоки, сколько сторонних модулей поставили, аккуратно ли сделан обмен с 1С, какой сервер используется, какая версия PHP. Мы предпочитаем актуальный Битрикс, PHP 8.3 и минимальное число внешних модулей. Это не выглядит как эффектное решение, но именно в этих местах потом не сгорают сотни тысяч рублей на крупные доработки и исправления после обновлений.
Решение видно по схеме данных еще до выбора CMS
Я бы начинал не с дизайна и не с лицензии. Достаточно взять лист и за 15 минут нарисовать простую схему: откуда приходят данные, кто меняет цены, где живут остатки, сколько ролей у пользователей, куда уходит заявка, что должно измениться через год. По такой схеме выбор платформы обычно виден сразу.
Хорошие сигналы в пользу Битрикс такие:
- есть обмен с 1С и регулярное обновление остатков;
- нужен B2B-кабинет с ролями и ценами по группам;
- каталог подчинен бизнес-правилам: типам цен, остаткам, ограничениям по клиентам;
- контент и заказы ведут разные сотрудники в одной админке.
Альтернативную платформу я бы выбирал там, где продукт еще сам не договорился с собой: быстрый MVP, отдельный фронтенд, частые изменения сценариев, подписка или сложная логика доступа.
Самая дорогая ошибка здесь не в том, что вы переплатите за лицензию. Проблема в другом: команда привыкает считать ограничения платформы «особенностями проекта» и годами строит план разработки вокруг чужих правил.
