На созвоне мы уже обсуждали каталог, оплату и кабинет продавца, когда всплыл вопрос: кто отвечает за возврат, если товар продает селлер, а деньги принимает платформа. Через десять минут выяснилось, что не определены цены, остатки, модерация карточек и спорные заказы. В такой точке оценка в рублях уже не работает: вы считаете не продукт, а набор допущений.
Я видел это много раз. Команда хочет быстрее перейти к разработке, но потом требования переписываются по ходу проекта, и каждый новый сценарий сдвигает сроки и смету. У маркетплейса бюджет обычно сгорает не на витрине, а в логике сделки.
Сначала опишите сделку, потом считайте экраны
У маркетплейса минимум 3 роли: покупатель, продавец и платформа. Этого уже достаточно, чтобы проект стал заметно сложнее обычного интернет-магазина. Нужно заранее определить, кто принимает оплату, кто отвечает за брак, кто инициирует возврат, кто меняет карточку после модерации, кто фиксирует отмену заказа.
На одном проекте в B2B-оборудовании разговор выглядел так:
- "Продавец сам меняет цену?"
- "Наверное, да".
- "А после заказа?"
- "Это еще не обсуждали".
После такой реплики я обычно останавливаю оценку. Бюджет зависит от ролей, веток заказа и интеграций, а не от фразы "сделайте как Ozon".
После discovery на 2 недели мы сократили первый релиз с 42 экранов до 17 ключевых. Из сметы ушло около 1,8 млн ₽, а план стал короче на 9 недель. Цифры здесь довольно прямолинейны: когда бизнес-правила описаны заранее, код обходится заметно дешевле.
Если возвраты, выплаты, остатки и модерация не описаны, у вас еще нет маркетплейса. Есть дорогая идея о маркетплейсе.
Пять решений, без которых цена всегда плавает
До разговора о сроках я прошу зафиксировать пять вещей:
- кто ваши селлеры и почему им выгодно к вам зайти;
- как платформа зарабатывает: комиссия, подписка, платное размещение;
- кто ведет доставку и возвраты;
- кто принимает оплату: вы или продавец;
- с каким первым предложением вы выходите на рынок.
Даже базовый MVP с оплатой, модерацией и кабинетами легко дает 20-30 сценариев. Отдельная статья расходов - интеграции: платежный шлюз, 1С или ERP, доставка, email, SMS, push, аналитика. На одном запуске клиент считал их "парой строчек в плане", а по факту получил +35% к бюджету.
Мы предпочитаем тратить 2-3 недели на предпроектную аналитику. Обычно это 250-450 тыс. ₽, но экономия потом кратно больше. Логика здесь простая: сначала вы промеряете помещение, потом заказываете мебель. На словах быстрее идти в обратном порядке, по деньгам почти никогда.
Личный кабинет съедает больше бюджета, чем кажется
Запрос "нужен личный кабинет" почти всегда занижает объем. В маркетплейсе кабинетов несколько: покупатель, продавец, администратор. Именно здесь живет ежедневная операционка: товары, остатки, выплаты, споры, история изменений, ручные проверки.
Если продавец не может быстро обновить цену или статус, в процесс сразу включаются менеджеры платформы. Я видел это на практике: фонд оплаты труда рос быстрее выручки, потому что команда вручную исправляла то, что должен был делать кабинет.
| Блок | MVP | Полная версия |
|---|---|---|
| Товары | ручная загрузка | массовый импорт и шаблоны |
| Выплаты | 1 схема | несколько сценариев, акты |
| Команда продавца | один доступ | роли и права |
| Споры | через админа | отдельный модуль |
По стеку для таких задач мы чаще берем Laravel 11 или Node.js 20 + NestJS, база - PostgreSQL 16, кеш - Redis. Если каталог большой и нужен сложный поиск, добавляем OpenSearch. Нормально собранный кабинет обычно сокращает первый релиз на 20-30%.
Что в MVP нужно оставить руками
Маркетплейс редко проигрывает из-за того, что в первой версии нет чата, бонусов или реферальной механики. Чаще он ломается в момент, когда команда пытается автоматизировать все сразу. На старте ручная модерация, ручной разбор споров и одна схема выплат нередко полезнее, чем красивая, но сырая автоматизация.
У нас был проект в товарах для дома, где это сработало хорошо.
До:
- web + mobile в первом релизе
- рейтинги, бонусы, чат, акции
- срок 26 недель
- бюджет от 9 млн ₽
После:
- только web MVP
- каталог, заказ, оплата, кабинет продавца
- срок 12 недель
- бюджет около 4,7 млн ₽
Но был и обратный кейс, где мы пошли от старого интернет-магазина и просто "добавили продавцов". Это не сработало. Я бы сказал, это была ошибка в архитектурном допущении: магазин был рассчитан на одного владельца каталога, а маркетплейсу нужна другая логика данных и другая операционная модель. Через несколько месяцев пришлось перепроектировать админку и резать часть функций, потому что возвраты зависали, выплаты считались в таблицах, а карточки правили руками.
Что сделать за 3 дня, чтобы разговор о проекте стал предметным
Если вы всерьез думаете о запуске, я бы в ближайшие 3 дня сделал три вещи. В первый день - описал роли и ответственность по деньгам, возвратам и контенту. Во второй - разложил модули по трем колонкам: обязательно, можно вручную, позже. В третий - собрал 15-20 ключевых сценариев и список интеграций с пометкой, что критично для релиза.
Хороший стартовый документ часто помещается на одной странице. Но именно он отделяет проект на 6-12 месяцев от дорогой импровизации. Если через три дня у вас нет этой страницы, разработку пока рано начинать: вы все еще думаете за счет будущего бюджета.
