Разработка интернет-магазина на Laravel с админкой: состав работ, бюджет и приёмка

Вы заказываете магазин на Laravel, потому что обычная CMS не укладывается в ваши правила продаж. Но в предложении подрядчика написано только «каталог, корзина, оплата и админка». По такому списку трудно понять, что получит менеджер: рабочее место для обработки заказов или десятки таблиц, в которых страшно что-либо менять.

Ниже разберём состав разработки на примере магазина с вариантами товаров, учётом в 1С и доставкой. Вы сможете проверить смету, определить первую версию и договориться о приёмке до начала программирования. Это разбор для заказчика, а не инструкция по установке Laravel.

Сначала определите, ради чего нужна заказная разработка

Хорошая причина выбрать Laravel описывает конкретное ограничение бизнеса. Например, один заказ собирается из наличия двух складов и производства; покупатель согласует комплектацию с менеджером; цена зависит от договора, размера партии и выбранной обработки. Само по себе большое количество товаров ещё не доказывает, что готовая платформа не подойдёт.

Запишите три сценария, которые существующий магазин выполняет плохо. Для каждого укажите участников, исходные данные и правильный результат. Фраза «сложная ценовая политика» становится понятнее так: дилер видит цену своего договора, при покупке коробки получает дополнительную скидку, а стоимость доставки рассчитывается после распределения заказа между складами.

Затем попросите команду показать, как эти же сценарии решаются на готовой платформе. Если задача закрывается настройками и поддерживаемым модулем, собственный магазин может оказаться лишним расходом. Если требуется менять несколько связанных процессов, имеет смысл оценивать Laravel. Подробный способ сравнения есть в разборе Laravel и Битрикса.

Laravel не определяет, какой будет админка

Laravel даёт инструменты для разработки приложения. Из названия фреймворка не следуют ни карточка товара, ни обработка возврата, ни управление акциями. Эти возможности нужно собрать на подходящей основе и настроить под ваши данные.

Необязательно писать каждую функцию с нуля. Важно знать, что команда использует готовым, что изменяет и кто будет поддерживать эти изменения. Это должно быть видно в техническом предложении, а не выясняться при передаче проекта.

В официальном демо Filament можно посмотреть список заказов с фильтрами по состояниям. Это пример того, как может выглядеть рабочее место. Числа и покупатели на экране демонстрационные; наличие такого интерфейса ещё не подтверждает работу оплаты, резерва или интеграции с 1С.

Опишите товар так, как его продаёт компания

В магазине одежды одна модель может иметь размеры и цвета, но отдельный остаток, штрихкод и фотографию для каждого варианта. В продаже строительных материалов нужно различать цену за единицу и за упаковку. У производителя один артикул иногда дополняется параметрами изготовления. Эти случаи нельзя одинаково оценивать строкой «добавление товаров».

Подготовьте небольшой контрольный каталог: обычный товар, товар с вариантами, товар со скидкой, позицию под заказ и недоступный вариант. Добавьте реальные названия характеристик, единицы измерения и пример файла из учётной системы. По нему разработчик сможет проверить модель данных до массовой загрузки.

В документации Bagisto хорошо видно различие товара и его вариантов: в списке есть тип, артикул, цена и остаток. Используйте такой экран как повод обсудить свои данные. Например, должен ли менеджер редактировать остаток вручную, если его источником является 1С? Может ли он менять название для витрины независимо от названия в учёте?

Отдельно зафиксируйте, что происходит при смене артикула, объединении дублей, снятии товара с продажи и изменении адреса страницы. Иначе административное действие может сломать связь с учётом или убрать страницу, на которую уже приходят покупатели.

Спроектируйте путь заказа, включая неудобные ситуации

Основной сценарий прост: покупатель выбирает товар, оформляет заказ и оплачивает его. Для оценки разработки полезнее разобрать отклонения. Покупатель закрыл вкладку банка; уведомление об оплате пришло позже; менеджер изменил состав после согласования; один товар закончился во время оформления. Именно здесь появляются задачи, которых нет на макетах.

Статус заказа, состояние оплаты и состояние доставки лучше обсуждать отдельно. «Отменён» не сообщает, вернулись ли деньги и освободился ли резерв. В интерфейсе менеджера эти последствия должны быть видны, даже если операция запускается одной кнопкой.

Включите в смету работу менеджера и владельца

Попросите показать не только витрину, но и рабочий день сотрудника: найти новый оплаченный заказ, проверить наличие, изменить способ доставки, передать на сборку, обработать частичную отмену и найти причину ошибки. Для каждого действия нужны доступные поля, ограничения и подтверждение результата.

Контент-менеджеру могут понадобиться загрузка нескольких фотографий, черновики страниц, предпросмотр и массовое изменение характеристик. Руководителю нужны сведения об ошибках и возможность выгрузить данные. Эти задачи часто вспоминают после запуска, когда исполнители уже считают основную разработку законченной.

Составьте роли сотрудников и разрешения на опасные операции: изменение цены, возврат, экспорт покупателей, удаление товара. Проверка должна действовать на сервере. Скрытая кнопка сама по себе не запрещает операцию. Подробные сценарии собраны в статье о выборе админки для магазина.

Отделите запуск от развития, чтобы бюджет можно было контролировать

Для первой версии выберите завершённый способ продажи, а не набор наполовину готовых функций. Например: один каталог, розничные цены, один согласованный сценарий оплаты, доставка нужными способами и обмен основными данными с 1С. Дилерские договоры, сложную программу лояльности и конструктор наборов можно оценить отдельными этапами, если без них магазин способен принимать нужные заказы.

В CAPS заказная разработка интернет-магазинов начинается от 600 000 ₽. Это нижняя граница для обсуждения проекта, а не фиксированная цена любого магазина на Laravel. Состав интеграций, качество исходных данных, сложность админки и дизайн меняют объём работ. Срок и окончательная смета появляются после разбора задачи.

Сравнивайте предложения по одинаковым результатам. Если в одной смете «интеграция с 1С» означает загрузку каталога, а в другой ещё и двусторонние изменения заказов с журналом ошибок, разница в цене закономерна. Попросите разделить работу над сайтом, изменения в 1С, настройку внешних сервисов, перенос данных, проверку и обучение.

У каждого этапа должны быть результат, способ проверки, зависимости от заказчика и исключения. Например, «подключение оплаты» стоит расшифровать до выбранного провайдера, состояний платежа, повторных уведомлений и согласованного сценария возврата. Приёмка по названию функции оставляет слишком много места для разных ожиданий.

Заложите эксплуатацию до первого рекламного перехода

После публикации магазин продолжает зависеть от фоновых задач: обмена с 1С, писем, обновления поискового индекса. Сайт может открываться, пока очередь таких задач стоит. Поэтому проверка доступности главной страницы не заменяет контроль обработки заказов.

На официальном скриншоте Laravel Horizon показаны очередь, её нагрузка и ошибки заданий. Horizon применяется с очередями Redis; он не превращает приложение в надёжное автоматически. Команда должна настроить обработчики, права доступа, уведомления и правила повторного выполнения. Для другой архитектуры может использоваться другой инструмент.

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

В документации Laravel опубликованы сроки поддержки версий. Уточните выбранные версии PHP, фреймворка и административных пакетов, а также порядок обновления. Формулировка «используем современный стек» не заменяет этот список и бюджет сопровождения.

Принимайте работающий магазин по контрольным сценариям

Согласуйте сценарии вместе с сотрудником, который будет пользоваться системой. Дайте ему роль менеджера, а не полный доступ разработчика. Пусть он выполнит обычную задачу по инструкции и затем разберёт исключение. Так выявляются как ограничения прав, так и неудобные рабочие процессы.

1. Создайте контрольный товар с вариантами и проверьте каждый остаток на витрине.
2. Оформите покупку со скидкой и доставкой, сопоставьте состав и итог.
3. Повторите отправку заказа и уведомление о платеже в тестовой среде.
4. Проверьте обмен с 1С и повтор одного пакета данных.
5. Измените заказ из-под разрешённой роли и найдите запись в истории.
6. Проверьте оформление с телефона, клавиатуры и при ошибке заполнения.
7. Восстановите копию и проверьте контрольные товары и заказы.
8. Сопоставьте подтверждённый заказ с аналитикой и рабочим каналом уведомлений.

Скачать таблицу состава работ и приёмки. В ней можно отметить, что включено в первую версию, кто отвечает за данные и какое доказательство нужно получить от подрядчика.

Что подготовить для предметной оценки

Достаточно начать с примера каталога, трёх сложных заказов, названия и версии 1С, перечня оплат и доставок. Добавьте список ролей, существующий сайт и ограничения по запуску. Пароли и боевые ключи для первой оценки не нужны.

Если рассматриваете разработку магазина на Laravel с админкой, пришлите эти материалы в CAPS. Разберём, какие процессы стоит оставить готовой платформе, где нужна собственная логика и что включить в первую версию. Итогом обсуждения должен стать понятный состав работ, по которому можно сравнивать решения и принимать результат.