Разработка маркетплейса: с чего начать и сколько это стоит

Бизнес-контекст выбора архитектуры

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

Trade-offs: скорость vs гибкость

Первая версия маркетплейса не обязана закрывать все сценарии сразу. Разумный MVP обычно включает регистрацию и минимальную проверку продавца, карточку товара или услуги, оформление заказа, базовую модерацию и расчёт выплат. Сложную логистику — собственные склады, трекинг посылок в реальном времени, автоматизированную маршрутизацию доставки — на старте часто оставляют на стороне продавца или подключают внешнюю службу: платформа в этом случае фиксирует заказ, статусы и комиссию, а не строит логистическую сеть с нуля. Такой контур запускают, когда есть подтверждённый объём заказов и понятная юнит-экономика, а не заранее «про запас».

Когда хватает простого контура

Отдельный технический контур — как деньги от покупателя доходят до продавца за вычетом комиссии площадки. Нужны прозрачный баланс продавца, журнал операций, график выплат, формирование отчётов или закрывающих документов и обработка возвратов. Схема сильно зависит от юрисдикции и от того, кто выступает продавцом по чеку — эти вопросы решают юристы заказчика, а разработка закладывает архитектуру, способную работать с выбранной схемой. Платёжные провайдеры для разведения платежей между сторонами подключают под конкретную модель — например ЮKassa для расчётов внутри страны или Stripe, если среди продавцов или покупателей есть международные участники.

Когда нужна более сложная схема

• Минимальная проверка продавца при регистрации — реквизиты, контактные данные
• Правила для карточек: обязательные поля, запрещённые категории, модерация перед публикацией или после
• Система жалоб от покупателей и понятные статусы блокировки продавца
• Журнал действий модератора для разбора спорных ситуаций
• Более тяжёлый антифрод (KYC-провайдеры, скоринг транзакций) наращивают по факту атак, а не заранее

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

Как мигрировать без простоя

На странице услуги «Маркетплейсы» процесс описан так: погружение и фиксация задачи (1–2 недели), проектирование ролей, комиссий и интеграционного контура (1–3 недели), дизайн интерфейсов продавца и покупателя с проверкой в прототипе (2–4 недели), разработка спринтами с демонстрацией рабочих сценариев каждую неделю (3–16 недель), запуск с тестированием расчётов и обучением команды модерации (1–2 недели), развитие после запуска по активности продавцов.

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

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

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

1. Подрядчик сразу предлагает готовый конструктор маркетплейсов, не разобрав вашу модель комиссий и выплат — потом это упирается в кастомизацию биллинга
2. Нет обсуждения юридической модели платежей до старта разработки платёжного контура
3. MVP пытаются сделать «полным» сразу — с логистикой, автоматическим антифродом и множеством ролей — вместо того, чтобы проверить модель на упрощённой версии
4. Не закладывается роль модератора и журнал действий — при первом же споре между продавцом и покупателем разбираться не в чем
5. Подрядчик не спрашивает про объём и характер будущих продавцов — это напрямую влияет на архитектуру проверки и допуска

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