В прошлом году к нам пришел клиент с запросом «нужен маркетплейс под ключ» и списком из 47 экранов. После пары рабочих встреч стало ясно, что сам вопрос поставлен криво: еще не было ответа, кто приводит первую сторону сделки, почему вторая на платформе остается и где вообще появляются деньги. В такой точке обсуждать стек и цену рано - можно спокойно закопать 6-8 месяцев в автоматизацию того, что рынок потом не возьмет.
Я бы смотрел на это проще. Сначала собираем схему первой повторяемой сделки, потом выбираем архитектуру, потом решаем, что автоматизировать в релизе, а что пока вести руками.
Считать надо первую сделку, а не список функций
У маркетплейса главный риск обычно не в каталоге и не в дизайне кабинета. Проблема чаще в перекосе спроса и предложения. Если непонятно, кто приходит первым и зачем остается, разработка быстро превращается в гипотезу за 1,5-3 млн ₽.
На одном B2B-проекте в услугах клиент хотел каталог, рейтинги, чат, оплаты и мобильное приложение сразу. Мы оставили закрытую витрину, ручную модерацию исполнителей и распределение заявок через админку. Первые сделки пошли через 10 недель, хотя изначально планировали полгода.
Если первую сделку нельзя провести вручную, автоматизировать обычно еще рано.
MVP маркетплейса - это не минимальный интерфейс. Это минимальный набор процессов, который позволяет повторить сделку без ручного героизма со стороны команды.
Перед стартом я обычно проверяю вот что:
- кто создает первичное предложение
- почему участник не уйдет в прямую сделку мимо платформы
- за что можно брать деньги уже в первой версии
- какие шаги пока можно вести вручную
- какие данные реально нужны в MVP
Личный кабинет здесь - рабочее место
Фраза «нужен личный кабинет на сайте» почти всегда приводит к набору экранов. Но в маркетплейсе кабинет - это место, где человек делает работу: размещает товар, отвечает на заявку, загружает документы, смотрит выплату, решает спор.
Минимум есть 3 роли: покупатель, продавец, админ. Если сделать один универсальный кабинет, потом каждое новое состояние заказа начинает ломать права, уведомления и отчеты. Мы такое видели не раз.
У нас был проект, где операторы держали статусы в Excel и переписке. После перехода на раздельные кабинеты, историю изменений и payout-логику число ручных уточнений по заказам сократилось на 31% за 7 недель. Для бизнеса это означает простую вещь: меньше людей тратят день на пересылку сообщений между сторонами.
Частая ошибка здесь простая - один кабинет для всех ролей. Потом появляются десятки исключений в правах и статусах. Я бы сделал так: сначала описать сценарии по ролям, а уже потом рисовать экраны.
Для MVP почти всегда хватает модульного монолита
Короче, ранние микросервисы редко окупаются. Мы тоже пробовали идти этим путем на платформе в логистике: команда была 5 человек, продукт менялся каждую неделю, а время уходило в DevOps, очереди, трассировку и договоренности между сервисами. Через 3 месяца часть логики вернули обратно в один контур - так просто быстрее. Это как раз тот случай, где мы сами сначала переусложнили решение.
Для старта я бы сделал так: Laravel 11 или Node.js 20 + NestJS, PostgreSQL 16, Redis, очередь задач, OpenSearch, S3-compatible storage. Если домены разделены нормально, такая схема спокойно держит десятки тысяч SKU и тысячи заказов в месяц.
| Что сравниваем | Модульный монолит | Микросервисы |
|---|---|---|
| Запуск | быстрее | дольше |
| Поддержка | дешевле | дороже |
| DevOps | проще | заметно сложнее |
| Команда | 1 продуктовая | от 2-3 команд |
| Для MVP | хватает | рано |
/modules
/catalog
/accounts
/orders
/payments
/notifications
/admin
Комиссия не всегда лучшая монетизация
Многие ждут, что маркетплейс будет зарабатывать на комиссии с транзакции. На практике это работает только там, где сделка реально остается внутри платформы. Если продавцу важен поток обращений, а клиента легко увести в Telegram или звонок, комиссия начинает мешать раньше, чем приносить деньги.
У нас был сервисный проект, где команда вложилась в split payments, возвраты и сложный биллинг. На это ушло лишних 14 недель. После запуска продавцы спокойно уводили клиентов в мессенджеры, потому что ценность была не в оплате, а в самом лиде. Такая схема не сработала.
Потом модель поменяли: подписка для исполнителей плюс платные лиды, а комиссию оставили только в одной категории. Выручка появилась через 5 недель после смены схемы. Деньги пришли не там, где все ждали «настоящий маркетплейс», а там, где платформа действительно создавала пользу.
Цена растет из-за глубины автоматизации
Базовый MVP обычно можно собрать за 3-5 месяцев после подготовки на 2-4 недели. Но бюджет быстро уезжает вверх, когда в первый релиз добавляют KYC/KYB, split payment, логистику, мобильные приложения, антифрод, бонусы и сложную отчетность.
Проблема не только в часах разработки. Каждая юридически или финансово чувствительная функция тянет за собой тестирование, поддержку, документацию и разбор инцидентов. Разница между вменяемым MVP и перегруженным первым релизом легко дает x2-x3 по бюджету и еще +4-6 месяцев сверху.
Если есть сомнения, первый релиз лучше резать по живому:
- оставляйте только то, что сводит спрос и предложение в сделку
- все спорные процессы сначала проводите через админку
- автоматизируйте то, что повторяется каждую неделю
- мобильное приложение отложите, пока веб не показал спрос
Перед тем как заказывать маркетплейс под ключ, лучше ответить на один неприятный вопрос: если завтра убрать 70% функций, платформа все равно проведет сделку? Если нет, значит, вы пока строите не бизнес, а очень дорогую надежду.
