Облачная платформа: магазин внутри готовых правил
В облачной модели магазин работает в сервисе поставщика. Например, inSales описывает свою CMS как систему с витриной, товарами, заказами, оплатой, доставкой и интеграциями. На той же странице компания указывает возможности визуального редактора и изменения оформления через HTML и CSS.
Для владельца это удобная отправная точка: можно оценивать готовые рабочие экраны и настройку магазина. Но изменение внешнего вида ещё не показывает, насколько глубоко разрешено менять расчёт заказа, распределение остатков или правила скидок. Эти части нужно проверять отдельно по документации выбранной платформы и приложений.
Облачный вариант стоит рассматривать, если обязательные процессы укладываются в доступные механизмы. При сравнении выясните, какой тариф и приложения нужны именно вашему составу работ, где хранятся данные и как выгружаются товары и заказы. Условия могут меняться; фиксируйте их в предложении с датой проверки.
CMS на своём размещении: больше обязанностей у владельца
Другой вариант — система управления магазином, которую устанавливают и сопровождают в выбранной инфраструктуре. Например, WooCommerce работает поверх WordPress; официальное руководство отдельно рассматривает установку, товары, доставку, оплату и управление заказами.
Собственное размещение позволяет выбирать среду и исполнителя, но требует назначить ответственных за обновления, резервные копии и восстановление. Наличие администратора каталога не закрывает эти обязанности: редактор товара и специалист, который устраняет несовместимость расширений, выполняют разную работу.
У коммерческой CMS существенна ещё и редакция продукта. В сравнении лицензий «1С-Битрикс: Управление сайтом» возможности разнесены по комплектациям. Поэтому слова «магазин на Битриксе» недостаточно: в предложении нужны конкретная редакция, дополнения и их назначение. Совместимость с вашей конфигурацией учёта тоже требует отдельной проверки.
Собственная разработка: свобода за счёт отдельного продукта
Индивидуальное приложение имеет смысл обсуждать, когда важные правила торговли трудно реализовать штатными средствами выбранных платформ. Например, заказ должен проходить определённые согласования или собираться из взаимозависимых компонентов. Это возможные задачи, а не описание всех магазинов.
В таком решении кто-то должен спроектировать хранение товаров и заказов, административные операции, оплату, роли сотрудников, обновления и восстановление после ошибок. Студия или внутренняя команда становятся ответственными за эти части. Владельцу потребуется договориться, кто поддерживает систему после сдачи и как другая команда сможет продолжить работу.
Сравнивать индивидуальную разработку с готовой CMS следует по одинаковому конечному процессу. Эффектный конфигуратор на витрине может скрывать ручную сборку заказа в учётной системе. Если такая ручная работа приемлема на первом этапе, её стоит явно зафиксировать, а не оплачивать автоматизацию заранее.
Проверяйте платформу одним трудным заказом
Возьмите обязательный сценарий, который сложнее обычной покупки. Например: покупатель выбирает размер, применяет скидку, заказывает доставку в нужный регион, а после оплаты менеджер оформляет частичный возврат. Состав сценария определяется вашим процессом; добавлять необычные условия ради испытания не требуется.
Для каждого шага отмечайте механизм: штатная функция, названное расширение, доработка или ручная операция. Если потребуется собственный код, уточните, где он находится и как переживает обновление платформы. Если используется приложение, выясните, кто его поддерживает и что произойдёт при отключении.
Результатом должна стать демонстрация или документированная схема конкретного заказа. Перечень логотипов интеграций не показывает, передаются ли нужные поля и поддерживается ли возврат. Ограничение одного обязательного шага может исключить платформу ещё до обсуждения дизайна.
Проверьте поиск и работу с каталогом
Для магазина, который рассчитывает на поисковый трафик, нужны управляемые адреса категорий и товаров, доступные ссылки и правила обработки вариантов. Google объясняет, что лишние адреса одного содержимого и нестабильные параметры могут усложнять обход магазина. Эти правила полезны для проверки реализации; они не обещают поисковых позиций.
Попросите показать будущую категорию с фильтрами, карточку с вариантами и редактирование заголовков. Уточните, кто решает, какие сочетания фильтров доступны поиску. Возможность менять метатеги полезна, но сама по себе не определяет, какие страницы будут содержательными и нужными покупателям.
Посмотрите также на обычную работу сотрудника: изменение цены, массовую загрузку остатков, поиск ошибочной позиции. Если нужная операция доступна только программисту, учитывайте стоимость и скорость такого обслуживания.
Узнайте условия выхода до входа
У любой модели есть зависимость: от облачного поставщика, набора расширений или команды разработчиков. Заранее определите, какие данные можно получить при смене решения. Для каталога важны варианты, изображения и связи категорий; для заказов — состав, суммы, статусы и идентификаторы. Файл с названиями товаров не заменяет полную выгрузку.
Сравните расходы на разработку, необходимые подписки, поддержку и возможный перенос на одном периоде. Подтверждённую потребность в сложной функции учитывайте сейчас; неопределённые планы можно записать отдельно. Так у первой версии останется разумный объём, а техническая основа будет выбрана под реальную торговлю.
Торговые правила и ограничения выбранного решения можно закрепить в техническом задании, а расходы разных вариантов сопоставить по общему составу сметы.
Если вы выбираете между платформой и собственной разработкой, расскажите нам, как должен проходить заказ и с какими системами нужно обмениваться данными. В pommeDeTerre можно обсудить разработку интернет-магазина, границы первой версии и основания для выбора технологии.