Свой маркетплейс с нуля: с какого функционала начинать

Идея «сделать свой Wildberries» или отраслевую площадку для узкой ниши приходит владельцам бизнеса регулярно — и почти всегда упирается в один и тот же вопрос: с чего вообще начинать разработку. Если сразу закладывать в проект личные кабинеты продавцов, модерацию, рейтинги, встроенные платежи, программу лояльности и мобильное приложение, разработка маркетплейса растянется на год и съест бюджет, который лучше было бы потратить на привлечение первых продавцов и покупателей. В этой статье — конкретный минимальный набор функций, с которого стоит запускаться, и список того, что оправданно отложить.

Почему MVP маркетплейса — это не «сайт с каталогом»

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

Отсюда практическое следствие: MVP маркетплейса почти всегда крупнее MVP обычного сайта, но это не значит, что он должен быть большим. Задача первого релиза — доказать, что продавцы готовы размещаться, а покупатели готовы покупать, а не построить конкурента Ozon с первой итерации.

Обязательный минимум: без чего запуск не имеет смысла

Ниже — функции, без которых площадка физически не работает как маркетплейс, а не просто как сайт со списком товаров.

• Регистрация и профиль продавца. Форма подачи заявки, минимальный набор реквизитов (для юрлиц/ИП — обязательно), модерация вручную администратором перед публикацией магазина. Автоматизировать проверку документов на старте не нужно — 10-20 продавцов можно проверить руками за день.
• Личный кабинет продавца с управлением товарами. Добавление, редактирование, удаление позиций, простые остатки (число на складе или «в наличии / нет в наличии»), базовые категории и фото. Без раздельных складов, вариаций «цвет-размер-упаковка» и импорта из 1С — это следующие этапы.
• Каталог с фильтрами и поиском. Покупатель должен найти товар за 2-3 клика: категории, ценовой диапазон, сортировка по цене и новизне. Полнотекстовый поиск с опечатками и синонимами — задача второй итерации, для старта хватает поиска по названию и категории.
• Карточка товара с привязкой к продавцу. Покупатель должен видеть, кто именно продаёт товар — название магазина, ссылку на его страницу, контактные условия доставки. Это критично для доверия и для будущего разделения ответственности при спорах.
• Оформление заказа и корзина. Если товары в корзине от разных продавцов, заказ должен на бэкенде разбиваться на отдельные суб-заказы по продавцам — это архитектурное решение, которое дешевле заложить сразу, чем переделывать позже.
• Приём оплаты. Минимум — интеграция с одним платёжным агрегатором (например, ЮKassa или Т-Кассой) с оплатой на счёт площадки и последующей ручной или полуавтоматической выплатой продавцам. Полноценный сплит-платёж с автоматическим распределением по продавцам — не обязателен для первых сделок.
• Уведомления о заказе. Email или Telegram-уведомление продавцу о новом заказе и покупателю о статусе. Без этого продавец узнает о заказе только зайдя в кабинет — а зайдёт он не сразу.
• Административная панель платформы. Список продавцов и заказов, возможность заблокировать продавца или снять товар с публикации, базовая статистика по продажам. На старте это часто и есть основной инструмент контроля качества площадки.

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

Что стоит отложить на вторую волну

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

• Автоматический сплит платежей между продавцами. Пока заказов десятки в месяц, ручная выплата раз в неделю через бухгалтерию быстрее и дешевле, чем интеграция со сложным платёжным сплитом.
• Рейтинги и отзывы о продавцах. Система набирает смысл только при достаточном потоке заказов — отзыв на площадке с тремя продажами в месяц ничего не покажет покупателю и легко манипулируется.
• Программа лояльности, бонусы, промокоды. Инструмент удержания, а не привлечения. На старте важнее нарастить базовый поток заказов, чем удерживать тех, кто ещё не купил в первый раз.
• Встроенный чат покупатель-продавец. На MVP достаточно телефона или email в карточке магазина. Чат — это отдельная инфраструктура (история, модерация переписки, уведомления в реальном времени), которая оправдана при заметном объёме обращений.
• Мобильное приложение. Адаптивная мокап-версия сайта закрывает 90% сценариев на телефоне. Приложение стоит обсуждать только когда веб-версия уже подтвердила спрос.
• Расширенная аналитика и рекомендательные алгоритмы. «С этим товаром покупают» и персональные рекомендации требуют данных, которых на старте физически нет — рекомендовать не на чем.
• Автоматизированная модерация контента (антифрод, ИИ-проверка карточек). При 10-30 продавцах ручная модерация быстрее в разработке и точнее, чем настройка автоматических правил.
• Мультивалютность и мультиязычность. Нужны только если запуск изначально ориентирован на международный рынок — для регионального или нишевого российского маркетплейса это чистые издержки без пользы.

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

Архитектурные решения, которые дороже переделать, чем продумать заранее

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

• Разделение заказа на суб-заказы по продавцам. Если изначально в базе «заказ = один продавец», добавить мультипродавцовую корзину позже — это переписывание модели данных и логики оплаты, а не косметическая правка.
• Отдельные роли и права доступа (покупатель / продавец / администратор / модератор). Закладывается на уровне ролевой модели с первого дня, даже если на старте активна только роль продавца и администратора — добавлять новую роль в готовую систему авторизации дороже, чем предусмотреть расширяемость сразу.
• Логика статусов заказа. «Новый — принят — отправлен — доставлен — отменён» с понятными переходами между статусами. Плохо продуманная модель статусов на старте потом ломает интеграции с доставкой и уведомлениями.
• Идентификация продавца в каждой сущности. Товар, заказ, отзыв, выплата — всё должно с первого дня иметь привязку к product owner (продавцу), даже если функционал вокруг этой связи (например, отдельная страница магазина) появится позже.

Эти вещи не видны пользователю на демо, но именно они определяют, сколько будет стоить второй этап разработки.

Сколько времени и бюджета реально закладывать на MVP

На практике маркетплейс с описанным минимальным набором функций на базе типового стека (Laravel/PHP или Node.js на бэкенде, готовые компоненты для каталога и корзины, один платёжный шлюз) занимает от 6 до 12 недель разработки в зависимости от сложности каталога и специфики отрасли — например, маркетплейс услуг с бронированием времени сложнее маркетплейса физических товаров с фиксированной доставкой.

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

Практический вывод

Работающий маркетплейс на старте — это не уменьшенная копия Wildberries, а конкретный набор из восьми функций: регистрация и модерация продавцов, личный кабинет с управлением товарами, каталог с базовым поиском, карточка товара с привязкой к продавцу, мультипродавцовая корзина с разбивкой заказа, один способ оплаты, уведомления и админ-панель платформы. Всё остальное — рейтинги, чаты, сплит-платежи, мобильное приложение, рекомендации — решает проблемы масштаба, которых у площадки с первыми заказами ещё нет.

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