Как создать маркетплейс: практическое руководство по MVP

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

Что такое маркетплейс на самом деле

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

Данные

Чтобы вы и ИИ-конструктор правильно построили структуру, заранее перечислите таблицы: пользователи (с ролью), профили продавцов, объявления, фото объявлений, категории, запросы или бронирования, сообщения, а позже заказы, выплаты и отзывы. Заранее решите, какие поля обязательны для каждого объявления: несогласованные объявления делают поиск и фильтры бесполезными.

Права доступа

Маркетплейсы чаще всего ломаются на правах доступа. Запишите правила:

• Любой может просматривать опубликованные объявления.
• Редактировать или удалять объявление может только продавец, которому оно принадлежит.
• Покупатели видят только свои запросы и переписку; продавцы видят только запросы по своим объявлениям.
• Админы видят и модерируют всё.
• Контактные данные раскрываются только тогда, когда вы решили — например, после подтверждения бронирования.

Проверяйте это, входя под одним пользователем и пытаясь открыть страницы другого.

Решения и компромиссы

Начните узко

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

Кого привлекать первыми

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

Как двигаются деньги

Это самое важное решение, и у него три распространённых варианта:

1. Без платежей на платформе. Покупатели связываются с продавцами и платят им напрямую. Вы зарабатываете на плате за объявления, выделении в поиске или подписке для продавцов. Проще всего построить; слабее всего контролируете сделку.
2. Вы берёте плату только с продавца. Продавцы платят вам подписку или плату за объявление через обычную оплату. Всё ещё просто — это как любое платное приложение.
3. Покупатели платят через платформу, а вы выплачиваете продавцам. Вы берёте комиссию с каждой сделки. Именно это представляют себе большинство людей, и здесь же сложность.

Платежи и выплаты: честная версия

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

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

На практике это означает работу помимо кнопки оплаты:

• Онбординг и верификация продавцов. Каждый продавец проходит проверку личности и банковского счёта, прежде чем ему смогут заплатить. Некоторые застрянут и попросят вас о помощи.
• Вебхуки. Ваше приложение должно слушать события от платёжного провайдера — платёж прошёл, аккаунт продавца верифицирован, выплата не удалась — и обновлять свои записи.
• Возвраты, отмены и споры. Решите свою политику, затем сделайте так, чтобы программа её соблюдала, включая то, кто несёт расходы.
• Комиссии и отчётность. Комиссии за платежи и платформу влияют на вашу маржу; актуальные тарифы смотрите на сайте провайдера.
• Налоги и право. В зависимости от того, где работаете вы и ваши продавцы, могут быть налоговые, отчётные или лицензионные обязательства. Получите профессиональную консультацию, прежде чем держать или массово переводить чужие деньги.

Ни одно из этого не делает маркетплейс невозможным — просто выплаты заслуживают отдельного этапа с тестовым режимом, тестовыми аккаунтами и письменной политикой, а не одного промпта. Наше руководство по добавлению платежей в приложение описывает основы checkout, вебхуков и тестового режима.

Первый промпт для ИИ-конструктора

Опишите обе стороны, объявление, сделку и права доступа — а платежи в первую версию не включайте:

Создай MVP маркетплейса GearShare, где фотографы в Лиссабоне сдают друг другу фототехнику в аренду. Продавцы регистрируются, создают объявления (название, категория, описание, цена за день, до 6 фото, район) и видят запросы по своим объявлениям. Покупатели просматривают по категориям, ищут по ключевым словам, фильтруют по цене и району, открывают объявление и отправляют запрос на аренду с датами и сообщением. Каждый пользователь видит только свои запросы и сообщения. Добавь страницу админа, где новые объявления одобряются перед публикацией, и можно скрывать объявления. Всё сохраняй в базе данных, фото — в файловом хранилище. Пока без платежей — на подтверждённых запросах показывай «Договоритесь об оплате с владельцем». Удобный для телефона дизайн, чистый стиль.

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

Этапы создания

1. Выберите нишу и напишите два пользовательских сценария по нескольку предложений каждый.
2. Определите поля объявления и категории. Держите их компактными.
3. Постройте объявления и просмотр на реалистичных примерах данных.
4. Добавьте аккаунты и роли и проверьте каждое правило доступа.
5. Добавьте сделку — заявку, запрос на бронь или переписку.
6. Добавьте админку и модерацию: одобрение, скрытие, блокировка, редактирование.
7. Добавьте email-уведомления, чтобы люди знали о новом запросе.
8. Запустите с наполнением вручную в своей нише и смотрите на реальные сделки.
9. Только потом добавляйте платежи, начиная с тестового режима и небольшой группы проверенных продавцов.
10. Добавьте отзывы, когда будет достаточно завершённых сделок для отзывов.

Частые ошибки

• Строить выплаты до подтверждения спроса. Недели работы с платежами для маркетплейса, которым никто не пользуется.
• Слишком широкий запуск. Тонкое предложение в многих категориях выглядит пустым везде.
• Слабые права доступа. Продавец, который может редактировать чужое объявление, или покупатель, читающий чужую переписку, — серьёзный провал.
• Нет инструментов модерации. Спам и плохие объявления появятся быстро, как только вы станете публичными.
• Нечёткие политики. Отмены, возвраты и споры нуждаются в письменных правилах до того, как пойдут деньги.
• Фальшивая активность. Придуманные отзывы или объявления разрушают доверие и могут нарушать правила защиты потребителей. Наполняйте реальным предложением.
• Игнорирование утечки. Покупатели и продавцы, которые познакомились на вашей платформе, могут перейти к сделке вне её. Дайте им причину оставаться — защиту, удобство, репутацию — а не полагайтесь на скрытие контактов.

Расходы и инструменты

Текущие расходы MVP скромные: хостинг, база данных, файловое хранилище для фото и email-провайдер. Платежи добавляют комиссию за каждую транзакцию и, для платформенных продуктов, дополнительные платформенные сборы; актуальные тарифы смотрите на сайте провайдера. Самый большой расход — время: поддержка продавцов, модерация и разрешение споров.

Когда лучше готовый продукт

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

Создание с Mythex

Mythex может построить описанный выше MVP из чата: объявления, поиск и фильтры, процессы запросов и админ-страницу, с выделенной базой данных Postgres и файловым хранилищем, которые добавляются, когда приложению они нужны. Вход в приложение — по принципу «свой ключ»: вы выбираете подход, например email и пароль, хранящиеся в вашей базе данных, или внешний провайдер аутентификации, а агент всё подключает. Для платежей вы подключаете собственный аккаунт Stripe, а ключи хранятся как секреты проекта; готовой функции выплат для маркетплейса в один клик нет, поэтому онбординг Connect, вебхуки и логика выплат — это код, который вы создаёте, тестируете в тестовом режиме и которым владеете.

Полезная документация: создание CRUD-приложения, вход (свой провайдер аутентификации) и приём платежей через Stripe. Шаблон маркетплейса аренды даёт стартовый промпт, а наше руководство по MVP SaaS объясняет, как держать первую версию небольшой.

Вопросы