Клиент выбрал WordPress для CRM с 200 интеграциями. Через год мы переписывали всё с нуля на Laravel

Клиент выбрал WordPress для CRM с 200 интеграциями. Через год мы переписывали всё с нуля на Laravel

К нам пришёл Андрей — владелец оптовой базы стройматериалов. Уже был сайт на WordPress, уже был подрядчик, уже был год работы. Просьба звучала просто: «Ну вы же можете это доделать?»

Я открыл код. Семь плагинов для разных CRM. Кастомные таблицы в базе, не связанные ни с чем. REST-эндпоинты, написанные прямо в functions.php. И 200+ интеграций с поставщиками — через костыли из костылей.

Нет, доделать это было нельзя. Нужно было начинать заново.

Почему это вообще произошло

WordPress — отличный инструмент. Для блогов, лендингов, простых корпоративных сайтов. Проблема в том, что его берут по умолчанию, не думая о задаче.

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

Через 8 месяцев система падала раз в две недели. Добавить нового поставщика занимало 3–4 рабочих дня. А за год в это было вложено около 400 000 рублей.

Когда фреймворк важнее CMS

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

  • Нестандартная бизнес-логика, которой нет в плагинах
  • 10+ внешних интеграций (ERP, CRM, поставщики, платёжки)
  • Обработка данных в реальном времени — очереди, асинхронные задачи
  • Нужно API для мобильного приложения или внешних партнёров
  • Команда, которая будет развивать систему несколько лет

Для таких проектов мы выбираем Laravel. Не потому что он «модный» — а потому что он даёт структуру, которую можно поддерживать и масштабировать.

Что мы сделали с проектом Андрея

За 6 недель написали систему управления заказами и поставщиками на Laravel 11. Вот что изменилось:

Интеграции с поставщиками — добавление нового занимает 2–4 часа, а не три дня. Каждый поставщик — отдельный адаптер, структура одна, логика своя.

Очереди задач — прайс-листы от 200 поставщиков обрабатываются в фоне за 15 минут. Раньше это вешало сайт на полчаса и делалось вручную.

API для мобилки — менеджеры на складе смотрят остатки и принимают заказы с телефона. Написали за неделю поверх уже готового API-слоя.

Общий бюджет переписывания — 320 000 рублей. На 80 000 меньше, чем уже было потрачено на тупиковую ветку.

Но это не значит, что Laravel — всегда правильный ответ

Я убеждённый сторонник «правильного инструмента для задачи». Если нужен корпоративный сайт с блогом и формой заявки — Laravel избыточен. Битрикс или WordPress справятся за треть бюджета.

Если нужен интернет-магазин с нестандартными фильтрами и 50 000 товаров — сначала смотрим на возможности CMS. Часто хватает правильно настроенного решения.

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

  • Сколько внешних систем нужно связать?
  • Есть ли логика, которой нет ни в одном плагине?
  • Проект будет жить 3–5 лет и активно развиваться?

Если на три вопроса «да» — скорее всего, фреймворк окупится.

Цена ошибки выбора стека

За несколько лет работы я видел эту схему много раз. Сначала экономят 100–150 тысяч, выбирая «простое» решение. Потом тратят 300–500 тысяч на переписывание — и это ещё хороший сценарий. Плохой — когда система становится настолько запутанной, что её проще выбросить, чем починить.

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

Выбор технологии — это не технический вопрос. Это бизнес-решение, которое влияет на скорость, стоимость и жизнеспособность проекта на горизонте нескольких лет.