Интернет-магазин на Laravel

Когда Laravel нужен, а когда нет

• Laravel оправдан тогда, когда логика магазина выходит за пределы стандартной. Цена зависит от контрагента, объёма и валюты. Остатки живут в трёх складах и на маркетплейсе одновременно. Оптовик заходит в кабинет и видит свой прайс, свою отсрочку и свою историю отгрузок. Коробочное решение здесь либо переписывается плагинами до состояния, когда обновление становится риском, либо упирается в потолок на первом же нестандартном требовании.
• И наоборот. Если у вас 200 товаров, одна цена, одна доставка и план продавать — мы скажем это прямо на брифе и предложим готовую платформу. Выйдет быстрее и дешевле, а сэкономленные деньги уйдут в трафик. Мы делаем интернет-магазины на WooCommerce и не считаем это компромиссом — это просто другой класс задачи.
• Самая частая причина, с которой приходят за Laravel, — не «хотим фреймворк», а «текущая система не даёт сделать то, что нужно бизнесу». Это нормальная отправная точка. Тогда разговор начинается не с технологии, а со списка того, что сейчас делается руками.

Логика, ради которой это пишется

• Ценообразование, которое не укладывается в настройки коробки, — прайс-листы на контрагента, скидки за объём, персональные условия, несколько валют с курсом, цена за единицу измерения, акционные механики с ограничениями. Правила задаются в админке, а не в коде.
• Несколько складов и резервирование — остаток виден в разрезе складов, резерв держится под заказ, товар подбирается со склада ближе к покупателю. Продажа того, чего нет, перестаёт быть ежедневной историей.
• B2B-кабинет — свой прайс, лимит кредита, отсрочка, повторный заказ в один клик, счёт и закрывающие документы, история отгрузок. Если кабинетов много и в них есть свои роли, это уже ближе к веб-приложению по объёму — скажем об этом до подписания, а не в середине работы.
• Большой каталог и фильтры — отдельная поисковая подсистема (Meilisearch или Elasticsearch) вместо SQL-поиска, устойчивость к опечаткам, фасетные фильтры по характеристикам. Как это выглядит в самом тяжёлом варианте — на странице магазина автозапчастей.
• Фоновые процессы — очереди на импорт прайсов, пересчёт цен, отправку документов и писем. Большой прайс импортируется в фоне: сайт не ложится, менеджер не сидит у экрана.

Интеграции

• 1С и BAS — двусторонний обмен номенклатурой, ценами, остатками и заказами. Формат согласовываем с вашим 1С-специалистом до старта разработки, потому что это самый частый источник сдвига сроков.
• Оплата — LiqPay и Fondy, карты, Apple Pay и Google Pay, оплата частями, безналичный расчёт для юрлиц со счётом с сайта.
• Новая Почта — расчёт стоимости, выбор отделения или почтомата на карте, создание ТТН из админки, трекинг в кабинете покупателя.
• Маркетплейсы и фиды — выгрузка в Rozetka, Prom, Google Merchant Center и Meta, со своими правилами цен и остатков на канал.
• CRM и уведомления — передача заказов в вашу CRM или в Apros CRM, лид и статус заказа в Telegram, письма клиенту и менеджеру.

Код и доступы принадлежат вам

• Стандартный Laravel последней стабильной мажорной версии, без собственного фреймворка поверх фреймворка. Структура папок, именование, Eloquent, очереди, события — так, как написано в официальной документации. Любой Laravel-разработчик открывает проект и ориентируется в нём без нашего участия.
• Схема базы — только миграциями, в репозитории. Никаких изменений таблиц руками на боевом сервере, которые потом невозможно повторить.
• Репозиторий ваш с первого дня, мы в нём — участники. Доступы к серверу, домену, платёжкам и аналитике оформлены на вашу компанию. Хостинг выбираете вы, привязки к нашему нет.
• На сдаче — README с развёртыванием, описание переменных окружения, схема интеграций и форматы обмена, инструкция для контент-менеджера. Плюс созвон с вашим разработчиком, если он у вас есть, или с тем, кого вы наймёте потом.
• Тесты на критических путях — корзина, оформление, расчёт цены, обмен с 1С. Процент покрытия нас не интересует. Интересует другое: чтобы следующий человек менял код и видел, что ничего не сломал.