Когда бизнесу нужен новый сайт или внутренний сервис, вопрос технологии обычно появляется далеко не первым. Сначала есть задача: принимать заказы, работать с дилерами, автоматизировать расчёты, объединить данные из нескольких систем, дать клиентам личные кабинеты.
И только потом возникает вопрос: на чём всё это делать?
Для обычного корпоративного сайта WordPress может быть отличным решением. Для интернет-магазина иногда достаточно готовой CMS. Но бывают проекты, в которых попытка «доработать существующее» постепенно превращается в отдельную систему из плагинов, костылей и ручных операций.
Мы поговорили с Laravel-разработчиком о том, где проходит эта граница и почему кастомная разработка нужна далеко не каждому бизнесу.
Содержание
Если задача укладывается в возможности готовой CMS, Laravel действительно может быть не нужен. Например, компании требуется сайт с каталогом, новости, форма заявки и несколько посадочных страниц. Делать для этого отдельную систему на Laravel чаще всего бессмысленно — WordPress позволит запустить такой проект быстрее и дешевле.
Проблема начинается тогда, когда сайт перестаёт быть просто сайтом. Допустим, клиент говорит: «Нам нужен интернет-магазин». Начинаешь разбирать задачу, а выясняется, что:
Это уже не совсем интернет-магазин. Это бизнес-система, у которой просто есть веб-интерфейс. И вот здесь Laravel становится интереснее.
Можно. Но вопрос не в том, можно ли, а в том — что получится через два года? Это одна из главных ошибок при выборе технологии: обсуждается возможность реализации функции, но почти не обсуждается дальнейшая эксплуатация системы.
Представим проект: WordPress, WooCommerce и ещё 20–30 плагинов — один отвечает за цены, другой за роли, третий за импорт товаров, четвёртый за CRM, пятый за уведомления, шестой за поля заказа, седьмой за склады. Пока требования стандартные, всё может работать нормально.
А потом бизнес говорит: «Если клиент относится к дилеру категории A, находится в Минске и заказывает товар со склада №2, нужно сначала проверить его лимит, затем создать резерв на четыре часа и только после этого показать кнопку подтверждения заказа».
Каждый плагин знает свою маленькую часть системы, а бизнес-процесс проходит сразу через несколько частей. Разработчику приходится уже не просто реализовывать бизнес-логику, а искать способ заставить независимые плагины работать как единая система.
Нет. Это как раз слишком удобное упрощение. WordPress очень хорош там, где задача соответствует его природе: контентный сайт, корпоративный сайт, блог, небольшой каталог, относительно стандартный интернет-магазин.
Я бы скорее насторожился, если бы разработчик предлагал Laravel для любого проекта. Представьте небольшой сайт строительной компании: двадцать страниц, портфолио, новости, форма заявки. Зачем там Laravel? Клиент заплатит больше за разработку и получит систему, преимуществ которой практически не использует.
Технология должна соответствовать задаче, а не предпочтениям разработчика.
Обычно я смотрю не на количество страниц или товаров, а на бизнес-логику. Есть несколько характерных признаков.
Не просто товар → корзина → оплата → доставка, а, например:
заявка → проверка → уточнение → согласование → резерв → замена → повторное согласование → оплата → комплектация → доставка
Клиент, дилер, менеджер, руководитель отдела, сотрудник склада, бухгалтер, администратор — причём у каждого не просто разные страницы, а разные действия и ограничения.
Когда сайт должен постоянно обмениваться данными с CRM, ERP, 1С, складской системой, службами доставки и внешними API.
Когда система должна самостоятельно принимать решения по заранее заданным правилам. Вот тогда я уже рассматриваю проект не как сайт, а как приложение.
Допустим, компания продаёт сантехническое оборудование монтажным организациям. Обычная корзина здесь может оказаться слишком примитивной: монтажник собирает сантехнику для конкретного объекта, у него есть зоны — санузел, котельная, кухня, ввод воды — и в каждой десятки позиций.
Некоторые товары совместимы только с определёнными комплектующими. Какой-то позиции нет на складе — менеджер предлагает аналог, но монтажник должен подтвердить замену. После этого система должна пересчитать комплект, проверить совместимость, обновить состав проекта и зарезервировать товары. Если завтра монтажник изменит одну позицию, может потребоваться повторная проверка части проекта.
Фактически основной сущностью становится не «заказ», а целый проект объекта со своей историей изменений. В Laravel такую модель можно строить непосредственно вокруг бизнес-процесса.
Можно, и иногда именно так и стоит сделать. Но здесь возникает хороший вопрос: если значительная часть системы уже написана самостоятельно, что нам вообще даёт WordPress?
Если 80% проекта — собственная бизнес-логика, таблицы, роли, API и интерфейс, CMS постепенно превращается просто в оболочку для кастомного приложения. В какой-то момент проще честно признать: мы разрабатываем отдельную систему.
Сам по себе личный кабинет — нет. Личный кабинет, где человек видит свои заказы и меняет пароль, можно реализовать практически на любой CMS. Нужно смотреть, что пользователь делает внутри кабинета.
Например, дилер заходит в систему и видит индивидуальные цены, остатки по нескольким складам, кредитный лимит, документы, историю заказов, персональные условия и предложенные менеджером замены. Он собирает заказ — система проверяет доступность, предлагает замену, а если замена влияет на совместимость комплекта, заказ получает специальный статус и уходит менеджеру.
Вот это уже полноценный рабочий интерфейс. По сути — небольшое корпоративное приложение, а не «личный кабинет» в привычном смысле.
На старте — часто да. И это ещё одна причина не использовать её без необходимости. Но я бы разделял две вещи: цену первоначальной разработки и стоимость владения системой.
Можно быстро запустить решение на готовых модулях — первый год всё хорошо. Потом появляется новая интеграция, индивидуальное ценообразование, новая категория клиентов, меняется оформление заказа. Каждое изменение начинает затрагивать несколько сторонних модулей, и через три года простая доработка занимает неделю, потому что сначала нужно понять, что она может сломать.
Дешёвый старт не всегда означает дешёвую систему. Но и обратное тоже верно: нет смысла создавать дорогую архитектуру для бизнеса, которому она никогда не понадобится.
Не обязательно. Размер компании вообще не лучший критерий. Небольшая фирма из десяти человек может иметь очень сложный процесс — например, производство изделий под заказ.
Клиент отправляет параметры изделия. Система рассчитывает предварительную стоимость, менеджер уточняет характеристики, технолог подтверждает возможность изготовления, формируется окончательная цена, после оплаты заказ уходит в производство. У заказа появляются этапы:
замер → согласование → производство → контроль → доставка → монтаж
Для клиента всё это может выглядеть как простой сайт, но внутри работает достаточно сложная система. И наоборот: крупной компании иногда действительно достаточно обычного корпоративного сайта на WordPress.
Обычно проблема не в самой интеграции — отправить данные через API технически часто несложно. Сложности начинаются вокруг неё.
Допустим, сайт получает остатки товаров из учётной системы. Сразу появляются вопросы:
Вот эти вопросы обычно намного важнее самого API. Когда интеграций несколько, появляется целый слой бизнес-логики.
Возможность строить приложение вокруг предметной области бизнеса: клиенты, организации, заказы, проекты, согласования, резервы, замены, склады, документы, уведомления — и описать, как они взаимодействуют.
Не пытаться вписать всё в стандартную модель CMS «пользователь, товар, запись, заказ». Это особенно важно, когда система развивается несколько лет: хорошая архитектура позволяет добавлять новые процессы без необходимости каждый раз ломать существующие.
Конечно можно. Laravel сам по себе ничего не гарантирует — можно написать плохой проект на Laravel и отличный проект на WordPress.
Фреймворк не заменяет архитектуру. Если разработчик складывает всю бизнес-логику в несколько огромных контроллеров, через пару лет поддерживать такое приложение будет очень сложно независимо от технологии.
Поэтому вопрос должен звучать не только «на каком фреймворке будет проект?», но и «как будет организована система?»
Очень простую вещь: насколько безопасно будет менять систему после запуска.
Допустим, сегодня существует только обычный заказ. Через полгода появляется предварительный заказ, ещё через год — дилерский, потом компания запускает резервирование товара. Если система построена нормально, новые процессы можно добавлять постепенно. Если нет — любое изменение начинает цеплять всё приложение.
Для бизнеса архитектура проявляется не красивыми диаграммами, а стоимостью изменений.
Не обязательно. И я бы вообще не начинал разговор со слов «давайте заменим все ваши инструменты». Часто гораздо разумнее сделать систему, которая соединяет существующие процессы.
Допустим, сейчас заказ выглядит так: клиент отправляет Excel, менеджер проверяет позиции, пишет в мессенджер, отдельно смотрит остатки, потом вручную создаёт заказ в CRM. Вместо полной замены CRM можно сделать портал, который автоматизирует первые этапы.
Клиент загружает спецификацию — система сопоставляет позиции, проверяет наличие, находит проблемные товары и выделяет исключения. Менеджер работает уже только с проблемными позициями. После согласования готовый заказ отправляется в существующую CRM. Получается гораздо менее рискованный проект.
Нет — это опасная формулировка. Чаще полезнее убрать с сотрудников повторяющиеся операции.
Например, менеджер ежедневно получает 50 заказов и в каждом вручную проверяет наличие 30 позиций — это 50 × 30 = 1500 проверок. Но реально внимания требуют, допустим, только 80 позиций: товара нет, непонятен артикул, нужна замена, есть конфликт.
Хорошая система сама обрабатывает стандартные случаи, а человеку показывает только исключения. Менеджер перестаёт быть оператором копирования данных и занимается ситуациями, где действительно требуется решение.
Меняет, но не отменяет обычную бизнес-логику. ИИ хорошо подходит для неструктурированных данных: фотография, голосовое сообщение, Excel, свободное текстовое описание. Модель может помочь определить, что именно человеку нужно.
Но после этого всё равно должна работать обычная система — найти товар, проверить остаток и цену, определить замену, создать резерв, получить подтверждение. Поэтому я скорее рассматриваю ИИ как один из модулей приложения, а не как замену самого приложения.
Есть простой признак. Вы всё чаще слышите фразы вроде «так система не умеет», «можно, но после обновления может сломаться», «этот модуль конфликтует с другим», «нужно сначала выгрузить Excel», «менеджер потом вручную исправит», «эти данные хранятся ещё в другой таблице».
Одна такая проблема ничего не означает. Но если вокруг сайта постепенно появляется параллельная инфраструктура из таблиц, инструкций, ручных проверок, мессенджеров и дополнительных файлов — это уже сигнал. Возможно, бизнес-процесс стал сложнее системы, которая должна его обслуживать.
Не начинать с Laravel. Сначала нужно описать процесс: что происходит после заявки клиента, кто принимает решение, откуда берётся цена, где проверяются остатки, какие бывают исключения, кто может менять заказ, что требует подтверждения, какие действия сотрудники выполняют вручную, какие данные приходится переносить из одной системы в другую.
После этого иногда выясняется, что Laravel вообще не нужен — и это хороший результат анализа.
Если задача стандартная и уже нормально решается существующим продуктом: корпоративный сайт, небольшой интернет-магазин без сложной логики, лендинг, простой каталог. Писать отдельное приложение только потому, что разработчик хорошо знает Laravel, — странное решение.
Ещё одна ситуация — бизнес-процесс пока вообще не сформирован: компания хочет большую систему, но сама не понимает, как сотрудники должны в ней работать. В таком случае сначала полезнее проверить процесс на более простом прототипе. Иначе мы просто дорого автоматизируем хаос.
Когда программное обеспечение начинает отражать уникальную логику конкретного бизнеса — особенно если одновременно появляются нестандартные заказы, несколько ролей, сложные личные кабинеты, интеграции, автоматические проверки, согласования, фоновые операции, история изменений и разные сценарии для разных клиентов.
В этот момент вопрос уже не в том, какая CMS имеет больше функций. Нужно проектировать систему.
Если вам нужен сайт — сначала смотрите в сторону готовой CMS. Если вам нужна система, которая должна работать по правилам именно вашего бизнеса, тогда имеет смысл обсуждать кастомную разработку.
Laravel — не более «профессиональная» версия WordPress и не технология, которая автоматически делает проект лучше. Это просто другой класс инструмента — и использовать его имеет смысл там, где бизнесу действительно требуется собственная логика, а не очередной набор страниц и стандартных функций.
Выбор между Laravel, WordPress и готовой CMS лучше начинать не со сравнения технологий, а с процесса.
Если компания продаёт стандартный товар по стандартной схеме, готовое решение почти всегда стоит рассмотреть первым. Если же заказ проходит через несколько этапов, пользователи имеют разные роли, данные приходят из нескольких систем, сотрудники постоянно выполняют ручные проверки, а правила работы сложно выразить стандартными настройками CMS — задача уже ближе к разработке собственного веб-приложения.
Ценность Laravel — не в самом фреймворке, а в возможности построить систему вокруг реального процесса компании, вместо того чтобы годами подстраивать процесс под ограничения готовой системы.
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
Laravel или WordPress · micro-SaaS вместо очередного SaaS · Когда Laravel не нужен · Интеграция Laravel с 1С