Меня зовут Богдан Квитка, я руковожу компанией GoodFellazz. Мы больше десяти лет разрабатываем сайты и веб-приложения для производственных и торговых компаний, и работаем на Laravel и Vue. Вопрос «Laravel или Битрикс» я слышу почти на каждой первой встрече, и почти всегда в неправильной постановке.
Обычно его задают так, будто выбирают между двумя примерно одинаковыми вещами, как между двумя марками автомобиля. На деле это выбор между готовым продуктом и способом строить продукт под себя. Разница примерно такая же, как между покупкой типового загородного дома в посёлке и постройкой дома по своему проекту. Оба варианта разумны, но подходят они разным людям с разными задачами и бюджетами.
Эта статья для владельцев бизнеса, коммерческих и технических директоров, которые стоят перед выбором платформы и хотят понять экономику решения, а не выслушать очередную агитацию за конкретный стек. Я работаю на Laravel, и это стоит держать в голове при чтении. Поэтому я постарался опираться на проверяемые цифры: официальные цены Битрикса с сайта вендора, статистику распространённости технологий, наш собственный опыт на реальных проектах. Там, где я высказываю мнение, я честно помечаю это как мнение.
Сразу обозначу вывод, чтобы вы понимали мою позицию. Битрикс - хороший инструмент для типовых задач, и в ряде ситуаций я сам отговариваю клиента от кастомной разработки в его пользу. Laravel выигрывает там, где бизнес-логика перестаёт быть типовой. Дальше я разберу подробно, где проходит эта граница и как определить, на какой стороне находится ваша задача.
Короткий ответ
Если нет времени читать двадцать минут, вот суть в нескольких строках.
1С-Битрикс это готовая коробочная CMS, Laravel это фреймворк для разработки приложения под задачу. Сравнивать их напрямую не совсем корректно, потому что это разные категории продуктов.
Для типового интернет-магазина с публичными ценами, стандартной 1С и сжатым бюджетом обычно выгоднее Битрикс: всё готово, обмен с 1С в комплекте, запуск быстрее. Для сложного каталога с вариативными товарами, персональными ценами для дилеров, нестандартной 1С и планами активно развиваться обычно выгоднее Laravel: у него нет потолка продуктовой модели.
По деньгам за три года платформы сопоставимы, если считать одинаковые статьи расходов. Лицензия Битрикса на фоне общей сметы невелика, основной бюджет в обоих случаях это работа людей. Разница проявляется в стоимости изменений: нестандартная доработка на коробке нередко обходится дороже, чем разработка той же функции на фреймворке.
Быстрый способ определить свою сторону смотрите в разделе 14: чек-лист из десяти признаков сложности с правилом, как читать результат.
|
Ваша ситуация коротко |
Что скорее подойдёт |
|---|---|
|
Типовой магазин, публичные цены, стандартная 1С, малый бюджет |
1С-Битрикс |
|
Сложный каталог, дилерские цены, нестандартная 1С, развитие |
Laravel |
|
Визитка на несколько страниц |
Конструктор, оба избыточны |
01. Почему этот вопрос вообще возникает
Ситуация обычно выглядит так. Компания выросла, старый сайт перестал справляться, и руководитель начинает искать подрядчика. Он получает несколько коммерческих предложений, и в них фигурируют разные слова: одни предлагают Битрикс, другие фреймворк, третьи вообще Тильду. Цифры в сметах различаются в разы. Понять, за что именно берут деньги и почему такой разброс, со стороны бизнеса практически невозможно.
Добавляет путаницы то, что каждый подрядчик агитирует за то, что умеет сам. Битрикс-студия объяснит, что фреймворк это дорого и рискованно. Разработчик на фреймворке расскажет, что Битрикс тормозит и устарел. Обе стороны говорят правду наполовину, и обе умалчивают о том, что невыгодно им самим.
Правильный способ разобраться - перестать думать о технологиях и начать с вопроса о задаче. Сайт бывает разным по своей роли в компании. Для одних это визитка, которая должна просто обозначать присутствие компании в интернете. Для других это работающий инструмент продаж, через который проходят заявки, заказы и вся дилерская сеть. Технология под эти две задачи нужна совершенно разная, и цена ошибки тоже разная.
Поэтому дальше я буду постоянно возвращать разговор к одному: что ваш сайт должен делать и какую роль он играет в деньгах компании. Именно это, а не мода на технологию, определяет правильный выбор.
02. Главная путаница: это вещи из разных категорий
Первое, что нужно понять, чтобы весь дальнейший разговор имел смысл. Битрикс и Laravel относятся к разным категориям программных продуктов, и сравнивать их напрямую примерно так же корректно, как сравнивать готовый костюм из магазина с услугами портного.
1С-Битрикс: Управление сайтом - это CMS, система управления сайтом. Готовый коробочный продукт с админкой, набором модулей, шаблонами и магазином дополнений. Вы покупаете лицензию, устанавливаете продукт, настраиваете под себя из готовых блоков. Основная работа тут это конфигурирование и наполнение, а не программирование с нуля.
Laravel - это фреймворк, то есть каркас для написания собственного приложения. Он не даёт готовой админки и готового магазина из коробки. Он даёт разработчику проверенные инструменты, чтобы построить именно то приложение, которое нужно вашему бизнесу. Основная работа тут это разработка.
Разница фундаментальная, и из неё вытекает почти всё остальное. Готовый продукт быстрее и дешевле на старте, но ограничен тем, что в нём предусмотрели создатели. Фреймворк требует разработки, стоит дороже на входе, но не ставит потолка по функциональности. Аналогия с домом, которую я привёл во введении, работает буквально: типовой дом можно въехать и жить через неделю, но перепланировать несущую стену вы не сможете. Дом по проекту строится дольше и стоит дороже, зато он ровно такой, какой вам нужен.
Сводка различий
|
Параметр |
1С-Битрикс |
Laravel |
|---|---|---|
|
Категория |
Готовая CMS, коробочный продукт |
Фреймворк для разработки |
|
Что вы получаете |
Установленную систему с модулями |
Каркас, на котором пишется приложение |
|
Основная работа |
Настройка и наполнение |
Разработка под задачу |
|
Лицензия |
Платная, покупается |
Бесплатная, открытый код |
|
Готовый магазин и каталог |
Есть из коробки |
Пишется или собирается из пакетов |
|
Потолок по функциональности |
Ограничен архитектурой продукта |
Нет потолка продуктовой модели; остаются ограничения бюджета, команды и API контрагентов |
|
Порог входа для старта |
Низкий |
Высокий |
|
Кто целевой пользователь |
Типовой бизнес с типовыми процессами |
Бизнес с нестандартной логикой |
Одно важное уточнение, без которого сравнение будет нечестным. Когда я говорю «Laravel», я имею в виду не голый фреймворк, а собранное на нём приложение: выбранную админ-панель, слой каталога и корзины, поисковое решение, стратегию обновлений и сопровождения, команду и документацию. Сам по себе Laravel это заготовка, а не готовый сайт. Поэтому дальше по тексту я сравниваю конкретные вещи: 1С-Битрикс в типовом внедрении и кастомное приложение на Laravel с оговорённым составом работ, а не коробку против абстрактного потенциала. Без команды и продуманной архитектуры фреймворк сам по себе не заменяет ни CMS, ни магазин.
Есть ещё один продукт с похожим названием, который важно не путать. Битрикс24 - это отдельная система, CRM и корпоративный портал. Она бывает облачной и коробочной, и решает задачи внутренней работы компании, а не сайта. В этой статье я говорю про 1С-Битрикс: Управление сайтом, то есть про CMS для сайтов и интернет-магазинов. Дальше по тексту под словом «Битрикс» я имею в виду именно её.
03. Что такое 1С-Битрикс и как он устроен
Битрикс появился в 2001 году и за прошедшие годы стал самой распространённой коммерческой CMS в России. У него огромная экосистема: тысячи внедренцев, магазин готовых решений на несколько тысяч модулей и шаблонов, отдельная система сертификации разработчиков, подробная документация на русском языке. Для российского рынка это фактически стандарт де-факто в сегменте корпоративных сайтов и интернет-магазинов среднего размера.
Устроен Битрикс как модульная система. Есть ядро, а поверх него работают модули: интернет-магазин, каталог, блог, форум, рассылки, статистика и так далее. Набор доступных модулей зависит от редакции, которую вы купили. Поверх модулей ставится шаблон дизайна, и наполняется всё это через административную панель.
Отдельно стоит сказать про интеграцию с 1С, потому что это исторически сильная сторона продукта. Битрикс и 1С делает по сути одна экосистема, и стандартный механизм обмена данными идёт в комплекте. Для компании с типовой конфигурацией 1С это ощутимое преимущество. Стоит только уточнить формулировку, чтобы не создавать завышенных ожиданий: стандартный механизм это не то же самое, что готовый обмен без работы. Его всё равно нужно настроить, сопоставить поля, задать правила по ценам, складам и изображениям и протестировать выгрузку. Разработки в узком смысле для типового случая может не потребоваться, а проектирование и проверка нужны всегда.
Сильные стороны Битрикса как продукта я вижу так. Быстрый старт для типовых сценариев, потому что магазин и каталог уже написаны. Готовая интеграция с 1С для стандартных конфигураций. Большой рынок специалистов и готовых решений в России. Единый вендор, который отвечает за продукт и выпускает обновления безопасности. Понятная поддержка и обучение на русском языке.
Отдельно про экосистему готовых решений, потому что это и сильная, и слабая сторона одновременно. У Битрикса есть маркетплейс на несколько тысяч модулей и шаблонов: интеграции с транспортными компаниями, платёжные системы, дополнительные возможности каталога, готовые дизайны отраслевых сайтов. Для типовой задачи это экономит время, нужный модуль часто уже написан. Обратная сторона в том, что модули пишут разные разработчики, качество у них разное, и каждый установленный модуль это чужой код внутри вашего сайта. Сайт, собранный из десятка сторонних модулей, тяжелее обновлять и сложнее диагностировать, когда что-то ломается.
Слабые стороны тоже есть, и о них честно скажу. Архитектура продукта копилась двадцать с лишним лет, и в ней уживаются старое ядро и новое, из-за чего разработчику иногда приходится держать в голове два способа делать одно и то же. Глубокая кастомизация часто превращается в борьбу с самим продуктом. Обновление сайта, обвешанного десятком сторонних модулей, становится рискованной операцией, потому что апдейт может сломать несовместимый модуль. Лицензия платная, и за обновления после первого года надо доплачивать каждый год. Про деньги подробно поговорим в следующем разделе.
04. Сколько стоит Битрикс: редакции и цены 2026
Здесь я опираюсь на официальный прайс с сайта вендора, актуальный на 2026 год. С 1 января 2026 года 1С-Битрикс поднял цены на лицензии «Управление сайтом» примерно на 14-15 процентов, до этого цена держалась неизменной три года. Актуальные цифры всегда стоит сверять на странице покупки на 1c-bitrix.ru, потому что прайс меняется.
Продукт продаётся в нескольких редакциях, которые отличаются набором модулей. Чем выше редакция, тем больше возможностей и тем она дороже.
Цены на лицензии на 2026 год
|
Редакция |
Для чего |
Цена лицензии |
|---|---|---|
|
Старт |
Простой сайт, визитка, лендинг |
7 100 руб |
|
Стандарт |
Корпоративный сайт с контентом |
20 500 руб |
|
Малый бизнес |
Небольшой интернет-магазин |
47 000 руб |
|
Бизнес |
Полноценный интернет-магазин |
96 500 руб |
|
Энтерпрайз |
Крупные нагруженные проекты |
от 1 950 000 руб |
Ключевой момент, который часто упускают при расчёте бюджета. Лицензия покупается один раз, и в неё входит год бесплатных обновлений. Дальше, чтобы продолжать получать обновления, включая обновления безопасности, надо ежегодно продлевать лицензию. Продление стоит 25 процентов от цены редакции в год. Для редакции «Бизнес» это примерно 24 000 рублей ежегодно, для «Малый бизнес» около 11 750 рублей.
Формально сайт будет работать и без продления. На практике отказ от обновлений на коммерческом продукте, который является популярной целью для автоматических атак, это прямой риск безопасности. Поэтому продление стоит закладывать в бюджет как постоянную статью расходов, а не как опциональную.
Цена лицензии это лишь часть сметы, и обычно меньшая. Основные деньги уходят на работу внедренца: настройку, дизайн, вёрстку шаблона, доработку под ваши процессы, наполнение. Плюс хостинг, который для Битрикса рекомендуется брать с запасом по ресурсам, потому что продукт требователен к серверу. Плюс платные модули из маркетплейса, если типовой функциональности не хватает.
Важно: сама по себе лицензия Битрикса стоит недорого на фоне стоимости разработки. Ошибка в рассуждениях «Битрикс дешевле, потому что лицензия сто тысяч» в том, что лицензия это не основная часть бюджета. Полную стоимость владения мы посчитаем в разделе 07.
05. Что такое Laravel и кто за ним стоит
Laravel это PHP-фреймворк, который создал Тейлор Отвелл в 2011 году. PHP это язык программирования, на котором работает значительная часть интернета. По данным W3Techs, на июль 2026 года PHP используется примерно на 72 процентах всех сайтов, где известен серверный язык. Для сравнения, следующие по популярности языки идут далеко позади: Ruby около 6,7 процента, JavaScript на сервере около 5,9 процента, Java около 5,4 процента. То есть PHP это не нишевая экзотика, а самая распространённая технология для серверной части сайтов.
Среди PHP-фреймворков Laravel занимает первое место с большим отрывом. По данным исследования JetBrains The State of PHP, около двух третей PHP-разработчиков регулярно используют Laravel. Ближайший конкурент, Symfony, применяется примерно вдвое реже. На GitHub у Laravel порядка 84 тысяч звёзд, больше, чем у любого другого PHP-проекта.

За фреймворком стоит устойчивая коммерческая история, что важно для бизнеса, вкладывающегося в технологию на годы вперёд. В 2024 году компания Laravel привлекла инвестиции в размере 57 миллионов долларов от венчурного фонда Accel, того самого, который в своё время финансировал Facebook и Dropbox. Обновления выходят ежегодно, вокруг фреймворка выросла целая экосистема готовых инструментов для платежей, администрирования, поиска, очередей задач. Технология не заброшена и не привязана к судьбе одной небольшой команды.
Что даёт Laravel разработчику из коробки: авторизацию и управление доступами, работу с базой данных, отправку писем и уведомлений, фоновые задачи, кэширование, защиту от типовых атак. Всё это проверено на миллионах проектов по всему миру. Разработчик с первого дня занимается вашей бизнес-логикой, а базовую инфраструктуру ему писать не приходится. Подробнее про сам фреймворк я писал в отдельной статье Что такое Laravel и чем он полезен владельцу бизнеса, здесь же меня интересует сравнение с Битриксом.
Про экосистему готовых пакетов тоже скажу, потому что здесь частое заблуждение. Считается, что раз на фреймворке нет коробочного магазина, то всё пишется руками с нуля. Это давно не так. Вокруг Laravel выросло множество проверенных пакетов: готовые административные панели, движки поиска, инструменты для платежей, очередей, работы с файлами. Разработчик берёт эти компоненты и собирает из них приложение под вашу задачу, а не переписывает базовую инфраструктуру. Разница с маркетплейсом Битрикса в том, что пакеты Laravel это библиотеки для разработчика, а не готовые модули для установки в один клик. Гибкости больше, но и участие разработчика обязательно.
Слабые стороны у фреймворка тоже есть, и для честной картины их надо назвать. Готового магазина из коробки нет, каталог и корзину надо разрабатывать или собирать из пакетов. Порог входа на старте выше: нужна команда, а не один настройщик. Интеграция с 1С пишется под задачу, а не включается галочкой. Для простого сайта-визитки фреймворк это избыточное и неоправданно дорогое решение.
06. Сравнение по десяти критериям бизнеса
Перейду к предметному сравнению. Я выбрал десять критериев, которые реально влияют на решение владельца бизнеса, и по каждому даю честную оценку обеим сторонам. Сразу оговорюсь, что почти в каждой строке ответ звучит как «зависит от задачи», и это не уход от ответа, а суть дела.
Скорость выхода в онлайн
Здесь у Битрикса преимущество для типовых проектов. Магазин, каталог и корзина уже написаны, и на стандартном сценарии сайт можно запустить быстрее. Если ваша задача укладывается в то, что Битрикс умеет из коробки, вы выигрываете во времени. Laravel на старте медленнее, потому что функциональность разрабатывается. Оговорюсь, что на нестандартном проекте преимущество Битрикса тает: как только начинаются доработки под нетиповую логику, скорость падает, а иногда доработка на чужой архитектуре занимает больше времени, чем разработка с нуля.
Стоимость на старте
Битрикс дешевле на входе для типового проекта, и это честно. Лицензия плюс настройка готового решения обходятся меньше, чем разработка приложения. Laravel дороже на старте, потому что вы платите за разработку. Отдельная тонкость в том, что для сложного проекта разница сокращается, а иногда переворачивается, когда сложные доработки Битрикса начинают стоить как полноценная разработка.
Стоимость владения за годы
Тут картина обратная, и мы разберём её подробно в следующем разделе. У Битрикса есть постоянная статья расходов на продление лицензии, 25 процентов в год. У Laravel лицензии нет вообще, но есть расходы на хостинг и поддержку. На горизонте нескольких лет итог зависит от того, как активно развивается проект.
Каталог и товары
Для стандартного каталога Битрикс силён, всё готово. Для нестандартного каталога начинаются сложности. Вариативные товары со множеством исполнений, зависимые фильтры, где выбор одного параметра меняет доступные значения другого, персональные цены по договорам для разных категорий клиентов. Всё это на Битриксе делается через доработки, и чем дальше от типового магазина, тем тяжелее. На Laravel такой каталог проектируется напрямую под вашу номенклатуру. Мы подробно разбирали устройство сложного каталога в статье про разработку каталога для производителя.
Интеграция с 1С
Для типовой конфигурации 1С у Битрикса преимущество, обмен работает из коробки. Как только конфигурация 1С нестандартная или обмен нужен нетиповой, преимущество исчезает, и работа идёт руками в обоих случаях. Подробнее об этом в разделе 08.
Производительность
Здесь многое определяется руками, а не только платформой. Битрикс требователен к серверу, и на тяжёлом сайте с плохо написанными доработками он ощутимо тормозит. Правильно настроенный Битрикс с композитным кэшем работает нормально. Композитный кэш это встроенный в Битрикс механизм ускорения, который отдаёт посетителю заранее собранную статичную версию страницы, а динамические части подгружает отдельно. Laravel позволяет собрать более узкое приложение, которое несёт только нужный код, без балласта неиспользуемых модулей. Это возможность сделать легко, а не гарантия: плохо спроектированное приложение на Laravel тоже будет медленным, потому что скорость задаётся приложением, базой данных, кэшем, фронтендом и инфраструктурой в целом. Реальную разницу показывают нагрузочные тесты, а не свойства платформы на бумаге.
Безопасность
Обе платформы можно сделать безопасными и обе можно испортить. Битрикс это популярная цель для автоматических атак именно в силу своей распространённости: скрипты знают его структуру. Защищённость сильно зависит от того, обновляется ли продукт и не обвешан ли он сомнительными модулями. У Laravel защита от типовых атак встроена в фреймворк, а нестандартная структура кода менее предсказуема для массового сканирования. Это не делает Laravel неуязвимым, но убирает часть автоматических угроз.
Гибкость и нестандартная логика
Тут преимущество Laravel очевидно и вытекает из самой природы фреймворка. Любая логика, любые интеграции, любые процессы. У Битрикса гибкость ограничена архитектурой продукта, и за её пределами начинаются те самые доработки, которые дорого поддерживать.
Поддержка и развитие
У Битрикса поддержку обеспечивает вендор и большой рынок студий. Риск в том, что сайт с множеством кастомных доработок и модулей из маркетплейса тяжело обновлять, обновление может сломать кастом. У Laravel поддержка это ваша команда или подрядчик, обновления фреймворка проходят предсказуемо, но за поддержку надо платить отдельно, встроенного вендора тут нет.
Владение и независимость
Битрикс это лицензионный продукт, вы зависите от вендора, его цен и его решений о развитии продукта. С Laravel ситуация другая, и её стоит описать точно, без прикрас. При корректном договоре заказчик получает права на код приложения и может сменить исполнителя, лицензионных платежей вендору нет. Но открытость кода не означает полной независимости. Готовые пакеты, из которых собрано приложение, имеют собственные лицензии, а на смену подрядчика уходит время, и без документации и понятных стандартов разработки эта смена болезненна. То есть зависимость от вендора Битрикса заменяется зависимостью от вашей команды и качества её работы. Для одних компаний свобода от лицензии принципиальна, для других это не имеет значения, и честно признать оба этих риска правильнее, чем продавать Laravel как решение без обязательств.
Итоговая таблица
|
Критерий |
1С-Битрикс, типовое внедрение |
Laravel, кастомное приложение |
|---|---|---|
|
Скорость старта, типовой проект |
Сильно |
Средне |
|
Скорость старта, нестандартный проект |
Средне |
Сильно |
|
Стоимость на старте |
Ниже |
Выше |
|
Стоимость владения, активное развитие |
Выше |
Ниже или сравнимо |
|
Типовой каталог и магазин |
Сильно |
Средне |
|
Сложный каталог, вариативность |
Средне |
Сильно |
|
Интеграция с типовой 1С |
Сильно |
Средне |
|
Интеграция с нестандартной 1С |
Средне |
Средне |
|
Гибкость логики |
Ограничена продуктовой моделью |
Ограничена бюджетом и командой, но не продуктом |
|
Владение кодом |
Лицензия вендора |
Права на код по договору, зависимость от команды |
Как видно, ни одна платформа не выигрывает по всем строкам. Они выигрывают в разных сценариях, и правильный выбор определяется тем, какие строки таблицы важны именно для вашего бизнеса.
07. Стоимость владения за три года
Сразу честно про метод. Ниже не смета и не универсальный рейтинг платформ. Это ориентировочная модель для одного сценария: корпоративный сайт с каталогом для производственной или торговой компании. Она показывает, из каких статей складывается бюджет за три года. Точную стоимость определяют состав каталога, источники данных, правила цен, интеграции и уровень сопровождения. Чтобы сравнение было честным, я считаю для обеих платформ одинаковые статьи расходов, включая те, что часто забывают: инфраструктуру, обновления и безопасность, поддержку, развитие. Часть цифр помечена как допущение, потому что они зависят от рынка и конкретного подрядчика.

Ещё одна оговорка про симметрию. У обоих подходов есть постоянные расходы на сопровождение, которые легко упустить: обновления платформы, мониторинг, резервные копии, закрытие уязвимостей, реакция на инциденты. Существуют они и у Битрикса, и у Laravel, поэтому в таблице ниже эти строки стоят у обеих сторон. Я намеренно не свожу всё в один итоговый диапазон, потому что состав работ у конкретного проекта слишком разный, и единая цифра создавала бы ложное ощущение точности. Вместо этого даю диапазоны по строкам.
|
Статья расходов за 3 года |
1С-Битрикс, типовое внедрение |
Laravel, кастомное приложение |
|---|---|---|
|
Лицензия |
96 500 руб единоразово (редакция «Бизнес») |
0, лицензии нет |
|
Продление лицензии |
около 24 000 руб в год со второго года |
0 |
|
Запуск: разработка, дизайн, настройка |
400 000 - 1 200 000 руб |
500 000 - 1 500 000 руб |
|
Инфраструктура, хостинг |
180 000 - 432 000 руб |
144 000 - 360 000 руб |
|
Обновления и безопасность |
входит в продление плюс работа |
работа команды, по часам |
|
Мониторинг и резервные копии |
нужны, стоимость сопоставима |
нужны, стоимость сопоставима |
|
Поддержка и развитие |
по договору или по часам |
по часам при необходимости |
|
Платные модули из маркетплейса |
возможны |
обычно не требуются |
Что показывает такая раскладка. Лицензия Битрикса на фоне общей сметы это небольшая величина, и основные деньги в обоих случаях уходят на работу людей. Разговоры о том, что одна платформа в разы дешевле другой, не выдерживают проверки, когда статьи расходов выравнены. Разница проявляется в двух местах. Первое это структура: у Битрикса есть постоянная лицензионная статья, у Laravel её замещают расходы на поддержку и хостинг. Второе, и более важное, это стоимость изменений: когда через год понадобится нестандартная функция, на Битриксе сначала выясняют, впишется ли она в архитектуру продукта, и доработка нередко обходится дороже, чем разработка той же функции на фреймворке.
Важно: этот расчёт нужен для понимания порядка величин и состава бюджета, а не для подстановки в договор. Реальную смету считают по вашему объёму номенклатуры, интеграциям и уровню сопровождения. Если хотите, мы можем разложить именно вашу задачу по этим строкам на встрече.
08. Интеграция с 1С: где у каждого сильная сторона
Для производственных и торговых компаний интеграция с 1С часто становится решающим критерием, поэтому разберу её отдельно. Здесь есть распространённое заблуждение, которое стоит разобрать по частям.
Заблуждение звучит так: раз Битрикс и 1С от одной экосистемы, то интеграция всегда работает сама, а на фреймворке её каждый раз пишут с нуля и это дорого. Половина этого утверждения верна, половина нет.
Верно то, что для типовой конфигурации 1С у Битрикса реальное преимущество. Стандартный механизм обмена товарами, ценами и остатками идёт в комплекте. Если у вас типовая «1С:Управление торговлей» без глубоких доработок, обмен настраивается быстро, и это честный плюс Битрикса. Оговорюсь ещё раз: даже стандартный обмен требует настройки, сопоставления полей и тестирования, а не включается одной галочкой.
Чтобы было предметно, вот где обмен обычно обходится настройкой, а где почти наверняка нужна доработка. Это ориентир, конкретика зависит от вашей 1С.
|
Обычно достаточно настройки |
Обычно требует доработки |
|---|---|
|
Типовая конфигурация 1С без правок |
Самописная или сильно доработанная конфигурация |
|
Выгрузка товаров, цен, остатков |
Сложные правила цен по договорам и категориям клиентов |
|
Один тип цены, публичные цены |
Персональные прайсы в личном кабинете |
|
Обмен в одну сторону, из 1С на сайт |
Обмен в обе стороны с возвратом заявок в учёт |
|
Стандартные поля номенклатуры |
Характеристики в наименовании, нестандартные единицы |
Неверно то, что нестандартная интеграция на Битриксе бесплатна. Как только конфигурация 1С отходит от типовой, а у производителей это скорее правило, чем исключение, обмен приходится дорабатывать руками в обоих случаях. И вот тут архитектура продукта иногда мешает, потому что подстраивать чужой стандартный обмен под нестандартные данные бывает сложнее, чем написать обмен с нуля под конкретную задачу.
На нашем проекте zao-sms.ru мы столкнулись ровно с этим на стороне фреймворка. Учётная система клиента не соответствовала стандартным протоколам, данные приходили в формате, который типовой обмен не переваривает. Пришлось писать отдельное решение, которое правильно опознаёт товары и вытаскивает нужную информацию в том виде, в каком она реально лежит у клиента. На Битриксе эта же задача не решилась бы галочкой, потребовалась бы такая же ручная работа, только внутри чужой архитектуры.
Стандартный формат обмена, о котором идёт речь, называется CommerceML, его поддерживают обе стороны. Если ваш подрядчик, неважно на какой платформе, говорит про обмен по CommerceML, речь именно про него.

Практический вывод такой. Если у вас типовая 1С и типовой каталог, Битрикс сэкономит на интеграции, это его сильная сторона. Если конфигурация 1С нестандартная, каталог сложный, а обмен должен идти в обе стороны с попаданием заявок обратно в учёт, преимущество Битрикса в этой части сходит на нет, и выбор платформы определяется другими критериями. Подробно про то, как устроен обмен и где он ломается, я напишу отдельную статью, тема большая.
09. Производительность и безопасность
Эти два критерия часто становятся аргументами в спорах, и вокруг них много мифологии. Разберу трезво.
Производительность
Начну с честного тезиса: скорость сайта определяется в первую очередь руками разработчиков, а платформа задаёт условия, в которых эти руки работают. Плохо сделанный сайт будет медленным на любой технологии.
У Битрикса есть особенность. Продукт универсальный и несёт в себе много всего, поэтому он требователен к серверу, и на слабом хостинге это заметно. У него есть собственные механизмы ускорения, главный из которых композитный кэш, и правильно настроенный Битрикс на хорошем сервере работает вполне достойно. Проблемы обычно начинаются, когда на сайт навешано много доработок и модулей из маркетплейса разного качества, каждый из которых что-то подгружает.
Laravel даёт возможность собрать приложение из собственного кода, без балласта неиспользуемой функциональности. Плюс в экосистему в последние годы пришли инструменты, которые дополнительно ускоряют работу без переписывания кода. Повторю оговорку: это возможность сделать быстро, а не гарантия. Плохо спроектированное приложение будет тормозить на любом фреймворке, и подтверждать скорость нужно замерами в реальных условиях.
Про то, как скорость сайта напрямую влияет на заявки и позиции в поиске, я подробно писал в отдельном материале про скорость и деньги, повторяться не буду.
Безопасность
Тут важно развести два разных вопроса: защищённость самой платформы и защищённость конкретного сайта на ней.
Битрикс как продукт получает регулярные обновления безопасности от вендора, и в этом его сила. Слабость в другом: именно из-за огромной распространённости он популярная цель для автоматических атак. Скрипты знают структуру Битрикса наизусть, где лежат файлы, как выглядит страница входа, какие уязвимости бывают в популярных модулях. Сайт на устаревшей версии без продления обновлений, да ещё с модулями сомнительного происхождения, это открытая дверь. Защищённость Битрикса напрямую зависит от дисциплины обновлений.
У Laravel защита от типовых атак, таких как SQL-инъекции, межсайтовые атаки и подделка запросов, встроена в фреймворк и работает по умолчанию. Плюс нестандартная структура кастомного приложения менее предсказуема для массового сканирования, потому что не следует известному шаблону. Это дополнительный уровень защиты, а не панацея. Дырявое приложение можно написать на чём угодно.
Общий вывод по обоим критериям одинаковый и, наверное, скучный. Во многих практических случаях решающими оказываются квалификация команды и дисциплина эксплуатации, а не сам выбор между Битриксом и Laravel. Платформа влияет, и всё же меньше, чем принято думать в спорах. Проверяются оба свойства замерами, а не общими словами: для производительности это нагрузочные тесты и метрики скорости в реальных условиях, для безопасности это аудит и своевременность обновлений.
10. Пять мифов, которые мешают выбирать трезво
За годы переговоров я собрал набор устойчивых заблуждений, которые звучат с обеих сторон. Разберу пять самых частых, потому что они мешают принять взвешенное решение.
Миф 1. Битрикс всегда тормозит
Неправда в такой категоричной форме. Правильно настроенный Битрикс с композитным кэшем на нормальном сервере работает достойно. Тормозит обычно не сам Битрикс, а сайт, обвешанный тяжёлыми доработками и модулями сомнительного качества на слабом хостинге. Обвинять платформу тут примерно так же справедливо, как винить марку машины за то, что владелец не менял масло.
Миф 2. На Laravel всё приходится писать с нуля, это долго и дорого
Устаревшее представление. Как я описывал в разделе 05, вокруг Laravel выросла зрелая экосистема готовых пакетов, и базовую инфраструктуру разработчик не пишет заново, она уже есть. Он занимается вашей бизнес-логикой. Многое из того, что три года назад делалось руками, сейчас собирается из проверенных компонентов.
Миф 3. Битрикс проще, потому что там всё готово
Верно лишь для типовых задач. Как только вам нужна нестандартная логика, «всё готово» превращается в «всё готово не так, как надо», и начинается доработка чужой архитектуры. Это часто сложнее, чем построить нужное с нуля. Простота Битрикса заканчивается ровно там, где заканчивается типовой сценарий.
Миф 4. Laravel это модно и несерьёзно, для стартапов
Прямо противоположно фактам. PHP работает на 72 процентах сайтов, Laravel это самый популярный фреймворк для этого языка, за ним стоят крупные инвестиции и ежегодные релизы. На нём работают проекты мирового масштаба. Про это я собрал отдельную подборку из 20 известных сайтов на Laravel. Несерьёзной технологией с двумя третями рынка PHP-разработчиков не бывает.
Миф 5. Раз у меня 1С, то однозначно Битрикс
Полуправда, которую я разбирал в разделе 08. Для типовой 1С это разумный аргумент. Для нестандартной конфигурации, а у производителей она чаще нестандартная, преимущество Битрикса в интеграции сильно уменьшается, и решать надо по совокупности критериев, а не по одному этому.
11. Когда правильный выбор - Битрикс
Я работаю на Laravel, и тем важнее мне честно назвать ситуации, где я сам порекомендовал бы Битрикс. Если ваша задача попадает в этот список, платить за кастомную разработку смысла нет.
Типовой интернет-магазин со стандартным сценарием. Публичные цены, обычная корзина, оплата картой, доставка. Битрикс написан ровно под это, и готовое решение обойдётся дешевле и запустится быстрее.
Типовая конфигурация 1С без глубоких доработок. Если учёт ведётся в стандартной 1С, встроенный обмен Битрикса экономит реальные деньги и время на интеграции.
Ограниченный бюджет и сжатые сроки. Когда запустить нужно быстро и недорого, а требования укладываются в типовой функционал, коробка честнее кастома.
В штате есть свой Битрикс-разработчик. Тогда сайт развивается своими силами, и это снижает стоимость поддержки. Менять платформу под имеющуюся компетенцию нелогично.
Каталог и процессы типовые и не планируют усложняться. Если бизнес-логика простая и таковой останется, потолок Битрикса вы не достанете, а за гибкость фреймворка переплачивать незачем.
Нужен быстрый корпоративный сайт среднего размера. Для контентного сайта компании с новостями, каталогом продукции и формами Битрикс редакции «Стандарт» закрывает задачу без разработки.
Общий признак всех шести ситуаций один: ваша задача похожа на то, для чего Битрикс создавался. Пока она типовая, готовый продукт это разумная экономия.
12. Когда правильный выбор - Laravel
Теперь обратная сторона. Ситуации, где готовый продукт упирается в потолок, и разработка на фреймворке оправдывает свою цену.
Сложный каталог с вариативными товарами. Одна модель в десятках исполнений, зависимые характеристики, где выбор параметра меняет доступные значения других. На фреймворке это проектируется под вашу номенклатуру напрямую.
Персональные цены и условия для дилеров. Когда цена перестаёт быть свойством товара и становится свойством пары «товар и клиент по договору», типовой магазин начинает трещать.
Нестандартная интеграция и автоматизация. Обмен с нетиповой 1С, связка с ERP, автоматическая генерация документов, сложные бизнес-процессы. Всё, что выходит за рамки типового обмена.
Личный кабинет дилера или партнёрский портал. Сложная система ролей и доступов, история заказов, документооборот, персональные каталоги. Это уже полноценное приложение, а не сайт.
Требования к нагрузке и скорости, которых не вытянуть на плагинах. Когда производительность критична, а типовое решение с доработками её не обеспечивает.
Продукт, который будет активно развиваться годами. Если сайт это ядро бизнеса, которое постоянно обрастает новой функциональностью, свобода фреймворка и отсутствие потолка окупаются на горизонте нескольких лет.
Общий признак здесь зеркальный по отношению к разделу 11. Как только задача перестаёт быть похожей на типовой интернет-магазин и появляются исполнения, договорные цены, сложные роли и нестандартные интеграции, готовый продукт начинает обрастать доработками. Если объём нетиповых доработок продолжает расти, совокупная стоимость решения на коробке может стать выше, чем разработка под задачу. Момент, когда это происходит, зависит от конкретного проекта и не подчиняется единому сроку, поэтому его стоит оценивать отдельно, а не закладывать как правило.
13. Промежуточные варианты и миграция
Выбор редко бывает строго бинарным, и честно упомянуть промежуточные пути.
Битрикс с глубокой кастомизацией. Можно взять Битрикс и дорабатывать его под нестандартные задачи. Это рабочий путь, но у него есть предел рентабельности. Когда доля кастомного кода начинает превышать типовой функционал продукта, вы получаете худшее из двух миров: платите за лицензию и обновления, но при этом боретесь с архитектурой и рискуете сломать сайт при апдейте. Я видел проекты, где за несколько лет накопилось столько доработок и правок ядра, что обновиться стало невозможно, а переписывать пришлось всё сразу.
Headless-подход. Headless означает разделение системы на две части: одна отвечает за данные и админку, а витрина, которую видит посетитель, строится отдельно на современном фронтенде и получает данные через API. Такие связки встречаются, но это уже инженерное решение под конкретную задачу, а не выбор из коробки.
Миграция с Битрикса на фреймворк. Частый сценарий: компания выросла из Битрикса и переезжает на Laravel. Тут стоит держать в голове, что миграция это отдельный проект, а не «перенести и всё». Контент переедет, а вот дизайн, функциональность и позиции в поиске автоматически не переносятся, их надо переносить осознанно, с картой редиректов, чтобы не обрушить трафик. По опыту такой переезд занимает от нескольких недель до пары месяцев в зависимости от объёма. Если вы в такой ситуации, полезной будет наша статья про доработки и развитие проектов.
Начать с простого и усложнять. Иногда разумно запуститься быстро на готовом решении, проверить спрос, а потом вложиться в разработку. Стратегия рабочая, но считать её надо как два отдельных вложения, а не одно растянутое. Про логику выбора между быстрым и основательным стартом я писал в статье про конструкторы и кастомную разработку.
14. Как принять решение: вопросы к себе
Прежде чем выбирать технологию, стоит оценить свою задачу по проверяемым признакам. Проблема слов «типовой» и «сложный» в том, что они оценочные, поэтому переведу их в конкретные вопросы с ответами, которые можно посчитать.

Признаки сложности, которые сдвигают выбор к Laravel
Отметьте пункты, которые про вас. Это измеримые характеристики задачи, а не оценочные ярлыки.
Больше одного типа цены: разные цены для разных категорий клиентов или персональные прайсы по договорам.
Каталог с вариативными товарами, где одна модель существует в десятках исполнений.
Зависимые характеристики и правила совместимости, где выбор одного параметра ограничивает другие.
Больше двух ролей пользователей со своими правами: например дилер, менеджер, администратор.
Личный кабинет с историей заказов, документами или согласованиями.
Больше одного источника данных: 1С плюс складская система, плюс данные поставщиков.
Нетиповая или сильно доработанная конфигурация 1С.
Обмен с учётом в обе стороны, когда заявки с сайта должны попадать обратно в 1С.
Автоматизация процессов: генерация документов, расчёт спецификаций, сложные сценарии заказа.
Планы активно развивать функциональность в ближайшие два-три года.
Как читать результат
Правило простое и приблизительное, это ориентир для разговора, а не формула вместо инженера.
Ноль или один отмеченный пункт. Задача близка к типовой. Скорее всего вам подойдёт Битрикс, а иногда и вовсе конструктор. За гибкость фреймворка переплачивать незачем.
От двух до четырёх пунктов. Пограничная зона. Здесь всё решает конкретика, и стоит запросить два варианта сметы, на коробке и на фреймворке, чтобы сравнить не только цену, но и то, как каждый подрядчик планирует закрывать отмеченные вами пункты.
Пять и больше пунктов. Задача нетиповая. Коробка почти наверняка начнёт обрастать доработками, и разработка на фреймворке с высокой вероятностью окажется выгоднее на горизонте нескольких лет.
Отдельно держите в голове ещё три фактора, которые не про сложность, но влияют на выбор: есть ли в штате свой Битрикс-разработчик, насколько критичны скорость запуска и стартовый бюджет, важно ли вам владение кодом без лицензионной зависимости. Наличие своего Битрикс-специалиста, жёсткие сроки и ограниченный бюджет тянут в сторону коробки даже при нескольких отмеченных пунктах сложности.
И ещё одна развилка, которую легко упустить. Иногда правильный ответ звучит как «ни то ни другое, вам хватит конструктора». Если ни один пункт чек-листа не про вас, а сайт нужен как визитка, ни Битрикс, ни Laravel не нужны, хватит Тильды. Эту границу я разбирал в статье про конструкторы и кастомную разработку.
На практике: я всегда советую пройти чек-лист до разговора с любым подрядчиком. Тогда вы придёте на встречу с описанием своей задачи в конкретных признаках, и разговор пойдёт по делу.
15. Наши проекты и почему в них выбран фреймворк
Покажу на реальных проектах, где выбор в пользу фреймворка был обоснован задачей, а не предпочтением. Метрик по выручке и конверсии в открытом виде у меня нет, поэтому описываю состав работ, без выдуманных процентов.
Каталог гидроцилиндров с вариативными товарами
Для производителя гидравлического оборудования Строймашсервис мы делали каталог, в котором одна модель гидроцилиндра существует в большом числе исполнений по диаметрам и ходу штока. Здесь была нужна модель вариативных товаров, фильтрация по техническим параметрам и умный поиск, который находит позицию по фрагментам названия в произвольном порядке. Задача с такой вариативностью выходит за рамки типового магазина, и фреймворк дал возможность спроектировать структуру под конкретную номенклатуру.
Редизайн крупного магазина с нестандартным обменом 1С
Для интернет-магазина гидрооборудования ZAO-SMS мы переделывали каталог примерно на 40 000 товарных позиций с семью уровнями вложенности и писали нестандартную синхронизацию с 1С, потому что данные клиента не ложились в типовой протокол обмена. Отдельным требованием было сохранить позиции в поиске при переезде. Эта комбинация большого каталога, нетиповой интеграции и требований к миграции определила выбор в пользу разработки.
Конфигуратор на десятки тысяч артикулов
Для производителя архитектурной светотехники Z1 Lighting Tools мы собирали конфигуратор, который держит десятки тысяч артикулов и исключает невозможные сочетания параметров, чтобы нельзя было собрать несуществующее изделие. Проект делала команда из десяти человек примерно за десять месяцев, потому что помимо конфигуратора там были мультиязычность, конструктор страниц и админка с разграничением прав. Такая логика подбора это уже полноценное приложение, и строить её на готовом продукте было бы борьбой с архитектурой.
Общее у трёх проектов одно: во всех задача была нетиповой, и именно нетиповая логика, а не мода на технологию, определила выбор фреймворка.
Честно про обратную сторону
Здесь справедливое замечание: три кейса выше показывают только сторону Laravel. Причина простая и я назову её прямо. Мы студия кастомной разработки и на Битриксе не работаем, поэтому кейсов на Битриксе у меня нет и быть не может. Это не значит, что я не рекомендую коробку. Если у компании типовой розничный магазин, стандартная 1С, бюджет до нескольких сотен тысяч и запуск нужен через месяц, я прямо говорю, что кастомная разработка тут будет переплатой, и советую взять Битрикс или готовое отраслевое решение, а не нас. Такие разговоры у нас регулярны, и отказ от нецелевого для нас проекта я считаю частью честной работы. Проверить мою позицию просто: критерии в пользу коробки я собрал в разделе 11, и они не зависят от того, кто их пишет.
Другие наши работы собраны в разделе кейсы.
16. Частые вопросы
Что дешевле, Битрикс или Laravel
Для типового проекта Битрикс обычно дешевле на старте за счёт готового решения. На горизонте нескольких лет разница стирается, если считать одинаковые статьи расходов. Подробную симметричную раскладку по строкам я привёл в разделе 07, диапазоны там пересекаются, а решает не стартовая сумма, а стоимость будущих изменений.
У меня уже есть 1С, значит нужен Битрикс?
Не обязательно. Для типовой конфигурации 1С встроенный обмен Битрикса это реальное преимущество. Для нестандартной конфигурации, которая у производителей встречается часто, обмен дорабатывается руками на любой платформе, и наличие 1С перестаёт быть решающим аргументом. Смотрите на совокупность критериев из раздела 14.
Можно ли сделать сложный каталог на Битриксе?
Можно, и это важно сказать честно, без пропаганды. Битрикс не запрещает вариативные товары, сложные фильтры или интеграции, это делается через доработки. Вопрос не в том, возможно ли технически, а в цене и рисках. Чем дальше задача от типового магазина, тем больше кастомного кода нужно навесить на продукт, тем дороже поддержка и тем выше риск, что обновление что-то сломает. Поэтому решать стоит по совокупной стоимости на несколько лет и по тому, насколько глубоко доработки вмешиваются в архитектуру, а не по одному лишь вопросу «получится или нет». Оцените свою задачу по чек-листу из раздела 14: если отмеченных пунктов сложности много, доработка коробки, скорее всего, обойдётся дороже разработки под задачу.
Можно ли перейти с Битрикса на Laravel потом?
Да, это частый сценарий, и его механику я разобрал в разделе 13. Если коротко: миграция это отдельный проект со своим бюджетом, дороже всего в нём обходится сохранение позиций в поиске, и заниматься этим нужно с первого дня, а не в последнюю ночь перед запуском.
Насколько сложно найти разработчиков под каждую платформу?
Специалистов много под обе. Битрикс распространён в России, и внедренцев на рынке достаточно. Laravel это самый популярный PHP-фреймворк в мире, разработчиков на нём тоже много, и вы не попадёте в ловушку экзотической технологии, под которую некого нанять.
Что выбрать, если я пока не знаю, будет ли расти проект?
Разумный путь в такой неопределённости это честно оценить вероятность усложнения. Если шансы, что через год-два понадобится нестандартная логика, высокие, закладывайте фреймворк сразу, переделывать дороже. Если задача с большой вероятностью останется типовой, начните с готового решения и не переплачивайте за гибкость, которая может не понадобиться.
17. С чего начать
Если свести всю статью к одной мысли, она такая. Вопрос «Laravel или Битрикс» это не вопрос о технологиях, а вопрос о вашей задаче. Готовый продукт хорош, пока задача типовая. Разработка на фреймворке оправдана, когда логика перестаёт быть типовой и бизнес готов вкладываться в развитие. Обе платформы это рабочие инструменты, и обе бывают неправильным выбором, если применить их не по назначению.
Я не буду обещать, что фреймворк или коробка сами по себе принесут вам продажи. Продажи приносят рынок, цена и работа отдела продаж, а платформа лишь создаёт или ограничивает возможности. Что выбор платформы точно определяет, так это потолок функциональности и стоимость изменений на годы вперёд.
Три шага, которые можно сделать самостоятельно, не заказывая ничего:
Пройдите чек-лист из раздела 14. Отметьте признаки сложности, посчитайте и прочитайте результат по правилу. Это займёт пятнадцать минут и сразу покажет вашу сторону.
Опишите свою задачу словами бизнеса, а не технологий. Что должен делать сайт, какой каталог, какие цены, какая 1С, какие роли пользователей. С этим описанием разговор с подрядчиком пойдёт предметно.
Запросите смету у двух подрядчиков с разным подходом. Один на Битриксе, один на фреймворке. Сравните не только цифры, но и то, как каждый обосновывает выбор и как планирует закрывать отмеченные вами пункты сложности.
Если выбираете между Битриксом и Laravel, не начинайте со стека. Пришлите структуру каталога, описание вашей 1С и список ролей пользователей, и на первой встрече мы разложим задачу по критериям из этой статьи и честно скажем, где коробка оправдана, а где создаст лишние расходы. Для этого есть бриф, его заполнение занимает минут пятнадцать. Посмотреть, что мы делаем и на чём, можно в разделах веб-разработка и разработка на Laravel, а живые проекты собраны в кейсах. Скажу честно и в завершение: если после разговора окажется, что вашей задаче больше подходит готовое решение, я так и скажу, а не буду продавать разработку ради разработки.


