Платформа и витрина

TL;DR: контур «платформа и витрина» отвечает на два вопроса: на чём строим магазин и как покупатель выбирает и оформляет товар. Выбор платформы — это решение по 10 проверяемым критериям, а не по бюджету; витрина — это сценарий от категории до подтверждения заказа, который должен работать и в B2C, и в B2B-операции.

Границы контура

Этот контур отвечает за основу магазина и его витринный сценарий: модель поставки платформы, выбор товара, корзину и checkout. Он не дублирует настройку конкретной CMS — приёмочный порядок WooCommerce-стека ведётся в стеке WooCommerce, а общие стратегии комплектаций — в типах сайтов.

Данные и обмен между системами — в контуре интеграций, деньги — в контуре платежей, доставка — в контуре логистики.

Что должна покрывать платформа

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

• Каталог и товарные данные — категории, SKU, варианты, характеристики, наличие, цены. Как эти данные приходят в магазин, разбирает контур интеграций.
• Витрина — поиск, фильтры, карточка товара, корзина. Сценарий покупателя раскрыт в каталоге и checkout.
• Заказ как сущность — статусы, история изменений, обработка отмен и частичных оплат.
• B2B-режим — персональные цены, роли контрагентов, заказ менеджером (если модель торговли требует).
• Интеграционная поверхность — API для обмена с 1С, платёжными системами и службами доставки.

Критерии выбора платформы

Выбор платформы проверяется по фиксированному списку критериев, а не по демо и цене тарифа. Критерии упорядочиваются по весу проекта: для 3-месячного запуска вес смещён к скорости и тарифу, для долгоживущего B2B-портала — к владению кодом и B2B-возможностям.

Критерий	Что оценивать	На что влияет
Срок запуска	Сколько нужно до первой продажи: готовый магазин, доработка или разработка с нуля	Бюджет проекта и дата выхода
Владение кодом и данными	Кому принадлежит код витрины, заказы, клиентская база	Возможность уйти без потери истории, глубина кастомизации
Тариф или лицензия	Ежемесячный тариф SaaS, единоразовая лицензия, нулевая цена ПО при расходах на разработку и хостинг	Unit-экономика магазина при росте оборота
Расширяемость	Возможность добавить нестандартный сценарий без форка ядра	Способность выдержать новые модели торговли
API	Полнота и документированность API для каталога, заказов, клиентов	Объём интеграций с 1С, платёжами, логистикой
Экспорт данных	Возможность выгрузить каталог, заказы, клиентов целиком и в открытом виде	Риск привязки (vendor lock-in) и цена миграции
Инфраструктура	Где исполняется магазин: облако поставщика, свой VPS или выделенный хостинг	Расходы на поддержку, ответственность за доступность
Ответственность за обновления	Обновляет поставщик или команда проекта	Стоимость сопровождения и безопасность
B2B-возможности	Персональные цены, роли, быстрые заказы, лимиты заказов	Универсальная ли платформа или только B2C
Российские интеграции	Готовые связки с 1С, эквайрингом РФ (СБП, онлайн-кассы), службами доставки	Стоимость наладки связей

Юридические и налоговые конкретики (чеки, УПД/УКД, ЭДО) — в контуре платежей и документов; здесь важно только проверить, что платформа позволяет обмен этими данными.

Четыре модели поставки

Подробная страница — платформы магазина. Краткая карта:

1. SaaS — магазин как услуга на тарифе поставщика (Яндекс KIT, InSales, Shopify). Минимальный срок запуска, максимум ответственности у поставщика, границы кастомизации и экспорта.
2. Коммерческая коробка — лицензионное ПО с развёртыванием на свой хостинг («1С-Битрикс: Управление сайтом», CS-Cart, UMI.CMS Shop). Владение файлами и данными, платная лицензия, нужна команда разработки.
3. Open-source self-hosted — открытый код (WooCommerce, OpenCart) без лицензионных платежей, но с полной ответственностью за хостинг, обновления и безопасность.
4. Custom — собственная разработка на приложении-скелете (Laravel) с админ-инструментами (Filament); commerce-домен — каталог, корзина, checkout — разрабатывается или подключается проверенными пакетами.

Как модель торговли влияет на выбор платформы

Требования к платформе выводятся из модели торговли, а не наоборот. Несоответствие — частая причина переделок.

Модель торговли	Ключевое требование к платформе	Типовой риск неверного выбора
Собственный B2C магазин	Скорость витрины, мобильный checkout, готовые платежи РФ	Жёсткий платёжный модуль без СБП или чеков
B2C каталог-витрина	Показательный каталог и лид-формы без checkout	Платёжный модуль не нужен, но за него вложены деньги
B2B портал и оптовый каталог	Персональные цены, роли контрагентов, заказ по счёту и API	B2C-платформа без B2B-слоя — переделка витрины
Маркетплейс и агрегатор	Мультивендорность, split-платежи, кабинет продавца	Претендент без механики продавцов не может закрыть модель
Продажа на чужой площадке	Собственная платформа минимальна, важен обмен данными	Вложение в витрину, где покупатель не приходит

Порядок принятия решения

Выбор платформы — последовательность фиксированных шагов, а не обсуждение демо:

1. Зафиксировать модель торговли и бриф с её бюджетными ориентирами (см. модели торговли).
2. Составить список обязательных интеграций: 1С или другая учётная система, платёжные методы, службы доставки — начерно, без выбора поставщиков.
3. Отбросить модели поставки, не подходящие по срокам, владению кодом и данным, бюджету сопровождения.
4. Внутри оставшихся моделей сравнить представителей по таблице критериев, задав каждому одинаковые вопросы.
5. Проверить у финалиста export-сценарий: как уйти, если через год-два выбор окажется неверным.

Решение фиксируется письменно: выбранная модель поставки, альтернативы, критерии с оценками. Это защита от повторного «перевыбора» через полгода на эмоциях.

Частые ошибки при выборе

Ошибка	Проявление	Профилактика
Выбор по привычке	«Возьмём ту же CMS, что в прошлый раз», без сверки с текущей моделью торговли	Начать с модели торговли и её требований, не с имени платформы
Выбор только по цене старта	Дешёвый тариф или бесплатное ПО, дорогая поддержка и лимиты позже	Считать стоимость владения за год: тариф/лицензия + хостинг + разработка + интеграции
Игнор экспорта	Данные островком в SaaS, миграция через ручные выгрузки	Проверить экспорт каталога, заказов и клиентов до входа, не на выходе
Недооценка интеграций	1С и склад питаются вручную, заказы разносятся два раза	Составить матрицу интеграций до выбора, а не после
B2C-инструмент под B2B-задачу	Нет персональных цен и ролей, покупатели звонят и заказывают по почте	Проверить B2B-возможности по чек-листу модели B2B-портала
«Filament и будет магазин»	Готов бюджет только на админку, commerce-домен не закрыт	Читать раздел про custom-модель в платформах до оценки сроков

Специфика B2C и B2B в витрине

• B2C. Покупатель принимает решение сам, важны скорость загрузки, простота checkout, готовые способы оплаты (карта, СБП, при получении) и мобильный сценарий. Кастомизация платформы обязательно должна покрывать промо и оформление (см. каталог и checkout).
• B2B. Покупатель — организация с ролями и согласованиями. Платформа обязана давать выгрузку остатков, персональные цены по контрагенту, быструю выгрузку заказа в 1С. Время работы витрины критично для регулярных повторных закупок, а не для первой конверсии.

Что делать после выбора

1. Сверить платформу с бюджетом, брифом и документооборотом модели торговли.
2. Прочитать сценарий каталог и checkout и проверить, что выбранный инструмент покрывает каждый шаг.
3. Составить матрицу интеграций (1С, платежи, доставка) и сверить их с контуром интеграций.

Чего этот контур не решает

Выбор платформы не закрывает соседние контуры, а только открывает их:

• Проверенные платёжные методы — карта, СБП, чеки по 54-ФЗ, жизненный цикл платежа — это платежи и документы.
• Доставка и постпродажа — зоны, сроки, вручение, невыкуп, возврат товара — это логистика и постпродажа.
• Источники товарных данных и обмен с учётной системой — это данные и интеграции.
• Спрос и экономика магазина — каналы, конверсия, unit-экономика — это рост и аналитика.

Правило разделения: если вопрос о том, «где живёт функциональность», — это контур платформы; если «кто и по каким правилам исполняет», — соседний контур.

Связанные страницы

• Платформы магазина — четыре модели поставки, ограничения и представители каждой модели.
• Каталог и checkout — сценарий выбора и оформления заказа от категории до подтверждения.
• Модели торговли — источник требований к платформе по каждой торговой модели.
• Данные и интеграции — контур, который соединяет платформу с 1С, платежами и доставкой.

Материалы и источники

• Практики WPCraft — утверждённый порядок вопросов при сборке магазина.