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

Flutter подходит этой форме по прямолинейной экономической причине: маркетплейс и так несёт двойную продуктовую поверхность, и платить сверху ещё и двойную платформенную цену — ровно так двусторонние бюджеты и умирают. Одна кодовая база покрывает сценарии покупателя и продавца и на iOS, и на Android — а там, где роли расходятся настолько, что становятся отдельными приложениями, оба всё равно собираются из одного кода, ровно так же, как это делает наш white-label-парк.

Какие продукты мы делаем

  • Маркетплейсы локальных услуг — предложения и те, кто их ищет, в одном районе, как в OneTwoDo, который мы спроектировали и выпустили под ключ
  • On-demand-продукты — запрос, матчинг, выполнение: уборка, ремонт, сценарии в духе доставки
  • Маркетплейсы аренды и бронирования — инвентарь с календарями, доступностью и проблемами двойного бронирования, которые они приносят
  • Peer-to-peer-товары — объявления, предложения и чат, где происходит сама сделка
  • B2B- и нишевые маркетплейсы — где предложение курируется, а онбординг одной из сторон — операционная задача, которую приложение должно поддерживать

Кто будет делать ваш маркетплейс

Живой маркетплейс, спроектированный и выпущенный за семь недель

OneTwoDo — двусторонний маркетплейс локальных услуг для Perform Connect Studios S.L.: уборка, ремонт, сантехника и многое другое; объявления размещают исполнители, а просматривают соседи. Мы сделали продукт целиком: дизайн, Flutter-клиент и всё, на чём он работает. Мультивалютные цены, локализация на уровне объявления и лента, отфильтрованная по языку и локации, вышли в пределах тех же семи недель, в 2024 году.

Этот проект — ещё и наглядный пример честного скоупинга маркетплейса. Двусторонний продукт обычно подразумевает бэкенд-команду раньше всего остального; OneTwoDo вышел без написания этого слоя — Firebase для аккаунтов, объявлений, фотографий и аналитики, — что и позволило одной команде нести дизайн, клиент и бэкенд одновременно. Подходит ли такая архитектура вашему маркетплейсу — вопрос скоупинга, на который мы отвечаем до сметы, потому что он двигает и цифру, и календарь. Страница про MVP рассказывает ту же историю с точки зрения валидации.

Смежные мышцы: ленты, чат, реальное время

Маркетплейс — это обычно лента плюс разговор плюс транзакция. Каждую из этих частей мы выпускали на продакшен-глубине: лента с учётом геопозиции, чаты и каналы реального времени в Jepta, стриминговый чат Arcana, держащий тысячи сообщений при 60 fps, и платёжная дисциплина, описанная на нашей странице про финтех, — под руководством основателя, который вёл карточный процессинг на масштабе.

Что на самом деле требуют приложения-маркетплейсы

Холодный старт — продуктовое решение, которому приложение должно служить

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

Две роли, одна кодовая база — решение принимается осознанно

Одно приложение с переключателем ролей или два приложения из общего кода? Ответ свой у каждого продукта: переключатель ролей — когда большинство пользователей со временем могут делать и то и другое (peer-to-peer-товары), отдельные приложения — когда сторона исполнителя является рабочим инструментом со своими процессами (on-demand-флоты). Машинерию для обоих вариантов мы выпускали: потребительский парк кэшбэк-платформы и её отдельное приложение мерчанта собираются из одной кодовой базы. Неизменно одно: обе стороны специфицируются вместе, потому что каждая функция маркетплейса — это один сценарий, пересекающий два экрана, принадлежащие разным людям.

Поиск и матчинг — это и есть продукт

Покупатель судит о маркетплейсе по тому, показывает ли первый экран что-то релевантное. Это серверная работа — индексированный поиск, фильтры, отражающие то, как предложение реально описано, ранжирование, балансирующее свежесть, близость и качество, — поданная через клиент, который держит позицию скролла стабильной при пагинации и рисует карточки с тяжёлыми изображениями без рывков на среднем железе. Механика каталога пересекается с нашей страницей про e-commerce; разница в том, что инвентарь маркетплейса хаотичен, создан пользователями и всегда отчасти устарел — и UX обязан это переваривать.

Машинерия доверия: отзывы, профили, чат

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

Платежи, выплаты и деньги между ними

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

Ревью сторов при пользовательском контенте

Объявления, фотографии, чат и отзывы делают маркетплейс UGC по определению, и гайдлайн Apple 1.2 требует полного аппарата: модерация контента, механизм жалоб, блокировка пользователей и опубликованные правила. Команды обнаруживают это в последнюю неделю и выходят с опозданием; мы закладываем это в объём — вместе с удалением аккаунта и декларациями о данных, которые требуют оба стора.

Почему Flutter для маркетплейса

ТребованиеКак это решает Flutter
Две роли × две платформыОдна кодовая база там, где натив означал бы поверхность на четыре сборки
Оба стора на запускеПредложение и спрос редко делят одну платформу; без одного из сторов двусторонняя воронка режется вдвое
Ленты с тяжёлыми изображениями на дешёвых телефонахКомпиляция в нативный код держит сетки объявлений плавными на среднем Android
Чат, который ощущается мгновеннымСлой реального времени, построенный один раз, обслуживает обе роли — проверено на Jepta и Arcana
v1, которую можно итерировать еженедельноHot reload быстрее секунды, пока вы узнаёте, что на самом деле нужно вашей ликвидности

Где нативная разработка всё ещё выигрывает: если продукт по сути — возможность одной платформы (сценарий, начинающийся с App Clip, глубокая привязка к платформенному железу), кроссплатформенная экономия не главное, и мы так и скажем. Общая страница услуги — разработка на Flutter.

Как мы работаем

Проект с фиксированным объёмом. Мы полностью отвечаем за поставку — дискавери, дизайн, архитектура, разработка, публикация в сторах. OneTwoDo — это ровно эта модель. Наш процесс разработки описывает её неделя за неделей.

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и спринты — см. расширение команды.

В обоих случаях смету под задачу мы присылаем в течение двух рабочих дней после того, как разберёмся в требованиях.

Сколько стоит приложение-маркетплейс

Первый релиз, доказывающий ликвидность, — объявления, поиск, профили, чат или бронирование, один платёжный сценарий — это, как правило, проект от до уровня Business: от 1,4–2,7 млн ₽ за лёгкую валидационную сборку на managed-бэкенде вроде OneTwoDo до 2,7–5,4 млн ₽ за три-пять месяцев, когда продукту нужны собственный бэкенд, отзывы и сценарии выплат. Отдельные приложения исполнителей, платёжные рельсы маркетплейс-класса с эскроу или операционный инструментарий уводят в enterprise-работу: от от 8,1 млн ₽.

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

Частые вопросы

Что чаще всего спрашивают основатели, которые строят двусторонние продукты на Flutter.

Да, и аргумент структурный: маркетплейс и так удваивает вашу продуктовую поверхность, потому что каждая функция существует и для стороны предложения, и для стороны спроса, — а Flutter не даёт вам платить сверху ещё и двойную платформенную цену. Одна кодовая база покрывает сценарии покупателя и продавца на iOS и Android, ленты объявлений с тяжёлыми изображениями остаются плавными на средних устройствах, потому что Flutter компилируется в нативный код, а слой чата реального времени, нужный маркетплейсу, строится один раз. Мы спроектировали и выпустили OneTwoDo, живой двусторонний маркетплейс услуг, за семь недель ровно на этом стеке.
Лёгкий первый релиз на managed-бэкенде начинается с нашего опубликованного тарифа MVP, маркетплейс с собственным бэкендом, отзывами и сценариями выплат — это проект уровня Business за три-пять месяцев, а отдельные приложения исполнителей или платёжные рельсы в духе эскроу оцениваются как enterprise-работа — диапазоны опубликованы на этой странице и на странице разработки на Flutter, а не называются кулуарно. Три вопроса, которые двигают цифру сильнее всего: одно приложение или два, насколько умным должен быть матчинг на запуске и насколько глубоко идёт денежный поток.
Зависит от того, что такое сторона продавца — идентичность или рабочее место. Переключатель ролей внутри одного приложения подходит продуктам, где многие пользователи со временем делают и то и другое, как в peer-to-peer-товарах. Отдельные приложения подходят продуктам, где исполнители работают в приложении весь день и им нужны процессы, которых покупатели никогда не видят, как в on-demand-флотах. Оба приложения всё равно собираются из одной кодовой базы на Flutter — мы ведём парк из пятнадцати потребительских приложений плюс отдельное приложение мерчанта из одной кодовой базы, поэтому второе приложение — это результат сборки, а не второй проект.
Холодный старт выигрывают операции и фокус, но именно приложение решает, накапливаются ли эти усилия. Конкретно: онбординг исполнителя настолько лёгкий, что предложение публикуется с телефона за минуты, браузинг, полезный до критической массы, — через курируемые категории, а не пустую строку поиска, и географический фокус, встроенный в модель данных, чтобы продукт мог выигрывать по одному району за раз. Лента OneTwoDo фильтруется по локации и языку на уровне запроса ровно по этой причине.
Через платёжные рельсы маркетплейс-класса, а не через обычное оформление заказа: деньги приходят от покупателя, комиссия удерживается, выплата уходит продавцу, и спор может прервать любой шаг. Провайдеры вроде Stripe Connect существуют, чтобы онбординг продавцов, удержанные средства и связанные с ними обязательства по KYC были комплаенс-проблемой провайдера, а не вашей, и ранний выбор этих рельсов стоит больше, чем любой объём работы над интерфейсом оформления заказа. В приложении суммы — целые числа в наименьших единицах валюты от края до края, а состояние платежа принадлежит серверу и никогда не додумывается клиентом.
Относитесь к маркетплейсу как к пользовательскому контенту, потому что объявления, фотографии, чат и отзывы делают его таковым. Гайдлайн Apple 1.2 ожидает метод модерации, механизм жалоб, возможность блокировать пользователей и опубликованные правила — приложение без них может быть отклонено независимо от того, насколько отполировано всё остальное. Добавьте универсальные требования — удаление аккаунта и декларации о данных — и это становится полноценным пакетом работ. Мы закладываем его в объём с самого начала, и это одна из причин, почему наши сабмиты — фаза, а не лотерея.

Прочитайте кейс OneTwoDo о полной семинедельной разработке, разбор сроков о том, куда уходит календарь, или начните с пилларной страницы разработки на Flutter.