Сколько стоит разработка маркетплейса: покупатели, продавцы и выплаты
Подробный разбор бюджета маркетплейса: первая сделка, кабинеты продавцов, платежи, выплаты, модерация и работа админ-панели.
В Appfyl компактный MVP маркетплейса обычно стоит 1-1,5 млн рублей, если он проверяет один тип сделки с небольшим числом продавцов, а редкие исключения команда решает вручную. Продукт с самостоятельным подключением продавцов, комиссиями, выплатами, сообщениями, модерацией и полноценной админ-панелью чаще попадает в диапазон 1,5-3,5 млн рублей. Несколько рынков, сложная логистика, разные типы продавцов, усиленная защита от мошенничества и большое количество интеграций могут увеличить бюджет до 3,5-7 млн рублей.
Оцените приложение в коротком опросе
НачатьСначала определите модель маркетплейса
Под одним словом скрываются очень разные продукты. Товарный маркетплейс управляет каталогом, остатками, доставкой и возвратами. Сервис по заказу услуг — расписанием, заявками или бронированиями. Аренда требует залога, передачи имущества и разбора повреждений. В B2B-продукте могут понадобиться аккаунты компаний, согласования, счета и индивидуальные цены.
Нельзя достоверно оценить все эти модели по одному прайс-листу только потому, что везде есть покупатель и продавец. До расчета бюджета опишите первую сделку одним предложением. Например: «Клиент выбирает проверенного специалиста на двухчасовую уборку, оплачивает заказ, а площадка переводит деньги исполнителю после подтверждения выполнения». Формулировка «маркетплейс услуг» для оценки почти бесполезна.
Хороший способ отбирать функции предлагает руководство LOW/CODE по запуску маркетплейса: каждая функция первой версии должна помогать завершить основную сделку или решить проблему с ней.
Диапазоны стоимости
Это рабочие диапазоны Appfyl, а не фиксированные пакеты. На оценку влияют готовность дизайна, набор платформ, страны запуска, платежная схема, интеграции и количество операций, которые команда согласна временно выполнять вручную.
| Уровень продукта | Ориентир Appfyl | Что обычно входит |
|---|---|---|
| Компактный MVP | 1-1,5 млн рублей | Одна модель маркетплейса, аккаунты покупателей и продавцов, простые объявления, поиск, один сценарий сделки, небольшая админ-панель и ручная работа с редкими спорами |
| Развитый продукт | 1,5-3,5 млн рублей | Самостоятельная работа продавцов, комиссии, связанные выплаты, сообщения, отзывы, очереди модерации, возвраты, аналитика и полноценная админ-панель |
| Крупная платформа | 3,5-7 млн рублей | Несколько рынков или моделей продавцов, сложная логистика, разные валюты, развитые права доступа, защита от мошенничества и большое количество интеграций |
Чтобы MVP попал в нижний диапазон, его нужно сознательно ограничить. Например, первых 20 продавцов можно подключать вручную, объявления проверять силами команды, а запуск провести в одном городе. Это нормальный способ проверить, будут ли встречаться спрос и предложение. Проблема начинается не из-за ручной работы, а когда ее не учитывают и не дают сотрудникам подходящих инструментов.
Отдельно оцените покупателя, продавца и команду площадки
Покупателю обычно нужны регистрация, поиск, карточка предложения, оформление заказа или записи, состояние заказа и обращение в поддержку. Продавцу — подключение к площадке, профиль или витрина, управление предложениями, работа с заказами, остатками или расписанием, сведения о выплатах и уведомления. Админ-панель связывает эти стороны.
Даже короткая фраза в описании может скрывать большой объем. «Продавец создает объявление» означает форму, черновик, загрузку изображений, проверку обязательных данных, статус модерации, правила редактирования и причины отказа. «Покупатель пишет продавцу» означает права доступа к переписке, непрочитанные сообщения, уведомления, жалобы, хранение истории и доступ поддержки при разборе нарушения.
Полезно описать действия каждой роли отдельно, а затем отметить общие состояния: объявление, заказ, платеж, возврат, выплата и спор. Так противоречия становятся видны до начала разработки.
Платежи и выплаты определяют архитектуру
В обычном интернет-магазине деньги получает одна компания. Маркетплейс может принимать оплату в пользу независимых продавцов, удерживать комиссию, откладывать выплату до выполнения заказа и разбирать возвраты. Юридическая и техническая схема зависит от стран, правил платежной системы и отношений между площадкой, покупателем и продавцом.
Команде нужно заранее решить, кто считается продавцом для покупателя и выдает чек или иной платежный документ; когда рассчитывается комиссия; в какой момент продавец получает право на выплату; кто оплачивает комиссию при возврате; что происходит при неудачной выплате или споре после перечисления денег; кто отвечает за проверку личности и необходимые отчеты.
Такую схему нельзя проектировать только по макетам экранов. Для страны запуска ее стоит согласовать с платежной системой, юристом и специалистом по налогам. Технический материал Stripe о моделях отношений внутри маркетплейса помогает понять варианты, даже если вы будете использовать другого платежного партнера.
Доверие, модерация и споры — это функции продукта
Отзывы — только один из способов создать доверие. В зависимости от риска могут понадобиться проверка продавцов, правила публикации, история заказов, показатели ответов, жалобы на контент и понятный порядок разбора споров. Для продажи канцелярии и заказа человека домой нужны разные меры.
В первой версии нужно определить, что именно обещает площадка и какие сведения увидит поддержка. Если покупатель утверждает, что услуга не оказана, сотруднику могут понадобиться история заказа, переписка, состояние платежа, приложенные материалы и предыдущие решения по этому продавцу. Без этих данных поддержка будет собирать информацию через разработчиков и снимки экрана.
Модерация на старте может быть ручной. Но у объявлений и аккаунтов должны существовать понятные состояния: ожидает проверки, опубликовано, скрыто, отклонено, заблокировано. Админ-панель должна хранить причину и автора изменения. На такой основе позже можно строить автоматизацию.
Поиск, подбор и сообщения быстро увеличивают объем
Покупатель должен находить подходящее предложение. Для MVP часто достаточно категории, местоположения, доступности и нескольких фильтров. Персональная выдача, рекламные места и рекомендации на основе искусственного интеллекта имеют смысл после появления достаточного числа сделок и данных для проверки результата.
В маркетплейсе услуг вместо обычного поиска может работать подбор исполнителя по району, навыкам, расписанию, цене и готовности принять заказ. Лучше начать с прозрачных правил. Сложный алгоритм невозможно настроить, пока команда не знает, почему покупатели отклоняют предложения, а исполнители отказываются от заявок.
Сообщения полезны, когда сторонам нужно уточнить заказ, но они создают работу по хранению, уведомлениям, жалобам и модерации. Иногда структурированная форма заказа собирает нужные сведения лучше и не дает пользователям сразу увести сделку за пределы площадки.
Есть идея приложения и нужен трезвый следующий шаг?
Разобрать идею приложенияМинимальная полезная админ-панель
Иногда основатели убирают админ-панель ради экономии, а затем одобряют продавцов через таблицы, меняют заказы напрямую в базе и просят разработчиков оформить возврат. В результате любая операция становится медленной и рискованной.
В MVP админ-панель обычно включает проверку продавцов, модерацию объявлений, поиск заказов, состояние оплаты и выплаты, оформление возврата, ограничения пользователей и базовую историю действий. Сотрудник поддержки должен понимать, что произошло, не открывая технические журналы. Сложные отчеты, автоматическая оценка мошенничества и десятки ролей можно добавить после появления настоящего рабочего процесса.
Подробнее о разделении ежедневных действий и необязательных отчетов читайте в материале о разработке админ-панели.
Как может выглядеть разумный MVP
Возьмем местный маркетплейс услуг. Покупатель выбирает категорию, описывает задачу, видит несколько проверенных исполнителей, выбирает одного, оплачивает или подтверждает заказ и получает уведомления о состоянии. Исполнитель управляет профилем, доступностью и заявками. Команда площадки подключает исполнителей, настраивает категории, видит заказы и разбирает отмены.
В первой версии можно вручную проверять исполнителей, использовать фиксированную комиссию, работать в одном городе, подключить один способ оплаты и решать споры через поддержку. Скорее всего, пока не нужны аукционы, меняющаяся комиссия, внутренний кошелек, собственная валюта лояльности, социальная лента и автоматический расчет правил для нескольких стран.
Используйте чек-лист функций MVP маркетплейса, чтобы разнести идеи по трем группам: запуск, следующая версия и потом. Для каждой функции запуска основатель должен объяснить, как она помогает провести первую сделку или решить проблему с ней.
Архитектура и проверка качества
Обычно маркетплейсу нужны клиентские приложения или адаптивные веб-интерфейсы, серверная часть, база данных, хранение изображений, поиск, фоновые задания для уведомлений, платежная интеграция и админ-панель. У заказа должны быть явные состояния, а не одно поле, которое можно произвольно переписать. Историю движения денег лучше хранить отдельно от понятного пользователю названия этапа заказа.
Повторные запросы не должны создавать второй заказ, возврат или выплату. Права доступа нужно проверять для каждой роли: продавец не должен читать заказы другого продавца, а сотрудник поддержки — выполнять действия, которые ему не разрешены.
Минимальный набор проверок: успешный заказ, недоступное предложение, ошибка оплаты, отказ продавца, полный или частичный возврат, отмена, неудачная выплата, жалоба на сообщение, блокировка продавца и спор после завершения заказа. Такие сценарии полезнее длинного списка проверок отдельных экранов.
Расходы после запуска
Кроме разработки, нужно учитывать комиссию платежной системы, проверку личности, карты или поиск, почту и SMS, хранение файлов, наблюдение за ошибками, поддержку и модерацию. Одни расходы растут вместе с аудиторией, другие — с количеством сделок или продавцов. Даже площадка с хорошим трафиком может оказаться убыточной, если стоимость поддержки и выплат не заложена в экономику заказа.
Нужен и бюджет на обслуживание: изменения внешних сервисов, обновления магазинов приложений, безопасность и улучшение ежедневных операций. Первые месяцы покажут, какие ручные действия стоит автоматизировать в первую очередь. Небольшой резерв на развитие после запуска полезнее попытки предугадать все процессы заранее.
Что подготовить для точной оценки
| Вопрос | Что он помогает понять |
|---|---|
| Как выглядит первая сделка? | Определяет основной сценарий покупателя и продавца |
| Кто может продавать и как его проверяют? | Определяет подключение, проверку и модерацию |
| Когда и куда движутся деньги? | Определяет оплату, комиссию, возврат и выплату |
| Что может пойти не так с заказом? | Определяет поддержку, доказательства и разбор споров |
| Какие действия останутся ручными? | Показывает скрытую работу команды после запуска |
| В какой стране и валюте пройдет запуск? | Определяет платежные способы и необходимые консультации |
Добавьте простую схему состояний объявления, заказа и платежа. Если команда не может договориться по этим трем схемам, для фиксированной оценки еще рано. Начать сбор требований можно в интерактивном брифе Appfyl.
Материалы Appfyl по теме
- Разработка маркетплейса: функции, этапы и архитектура
- Чек-лист функций MVP маркетплейса
- Стоимость подключения платежей и подписок
- Разработка админ-панели
- Интерактивный бриф для оценки приложения
Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.
Превратите исследование в план запуска
Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.
Обсудить план приложенияГлавные выводы
- Оценка маркетплейса должна учитывать приложения покупателя и продавца, а также работу команды площадки.
- Компактный MVP в Appfyl обычно стоит 1-1,5 млн рублей; выплаты, сообщения, модерация и развитая админ-панель переводят продукт в более высокий диапазон.
- До выбора функций опишите первую успешную сделку и неудачную сделку, которую должна разобрать поддержка.
- Платежную модель, комиссию, возвраты и момент выплаты продавцу нужно проверить до начала разработки интерфейсов.
Полезные ссылки
Частые вопросы
Кроме покупателей, он обслуживает независимых продавцов. Поэтому нужны подключение продавцов, управление объявлениями, комиссии, выплаты, модерация, споры и инструменты команды площадки. В обычном магазине каталог, выполнение заказа и деньги контролирует одна компания.
Сознательно ограниченный MVP может занять около 8-12 недель после согласования функций и направления дизайна. Сложные платежи, несколько приложений, логистика, проверка личности и большое количество интеграций могут увеличить срок до 4-8 месяцев и более.
Иногда можно. Во время небольшого пилота система может точно рассчитывать задолженность перед каждым продавцом, а команда — переводить деньги по согласованной процедуре. Такой вариант все равно нужно проверить с платежным партнером и специалистами по стране запуска. Даже при ручном переводе продукт обязан хранить точную историю начислений и состояний.
Только если без них невозможно провести первую сделку или создать необходимое доверие. Иногда сообщения заменяет подробная форма заказа и канал поддержки. Отзывы полезны, но для них нужно определить, кто имеет право оставить оценку, можно ли ее изменить, как пожаловаться и что делает модератор.
Обычно из-за неопределенных правил денег и исключений. Комиссия, возврат, момент выплаты, неудачный перевод, отмена и спор затрагивают несколько ролей и систем. Если решать их поздно, приходится менять и архитектуру, и интерфейсы.