Если вы решили заказать мобильное приложение для маркетплейса, вы уже на шаг впереди конкурентов, которые до сих пор работают только через веб. Но именно на этапе выбора подрядчика большинство проектов либо умирают, либо выходят за бюджет в 2–3 раза. В этой статье — конкретные критерии, чек-листы и вопросы, которые нужно задать команде до подписания договора.
Почему маркетплейс — это не просто «приложение с каталогом»
Маркетплейс — двусторонняя платформа: покупатели, продавцы, логистика, платёжный шлюз, рейтинги, споры, уведомления. Это принципиально другая архитектура по сравнению с интернет-магазином. Типичный маркетплейс включает:
- Два мобильных приложения или одно с разными ролями (покупатель / продавец);
- Административную панель для модерации и аналитики;
- Интеграции с платёжными системами (ЮKassa, Тинькофф, СБП);
- Систему уведомлений (push, SMS, email);
- Логику комиссий, выплат и актов для продавцов;
- Поиск с фильтрами, рекомендательную систему.
Подрядчик, который делал только e-commerce-приложения, может не понимать этой специфики. Уточняйте на берегу: был ли у команды опыт именно с маркетплейс-логикой, а не просто с мобильной разработкой.
Как оценивать портфолио: на что смотреть
Портфолио — первый фильтр. Но красивые скриншоты ничего не говорят о качестве кода и соблюдении сроков. Вот что реально важно:
- Живые приложения в App Store / Google Play. Скачайте, потыкайте. Если приложение снято с публикации или последнее обновление было 3 года назад — плохой знак.
- Рейтинг и отзывы пользователей. Оценка ниже 3.5 при более чем 100 отзывах — сигнал о проблемах с UX или стабильностью.
- Нагрузка, которую выдерживает продукт. Спросите: сколько одновременных пользователей держит приложение? Как масштабировали инфраструктуру?
- Наличие именно маркетплейс-кейсов. Не просто «приложение для бизнеса», а платформа с несколькими продавцами и логикой транзакций.
Технический стек: нативная разработка или кроссплатформа
Один из первых вопросов, который задают клиенты: «Нативное или Flutter/React Native?» Однозначного ответа нет — всё зависит от задач и бюджета.
| Критерий | Нативная (Swift / Kotlin) | Кроссплатформа (Flutter) |
|---|---|---|
| Производительность | Максимальная | Близкая к нативной |
| Бюджет | Выше на 30–50% | Ниже за счёт единой кодовой базы |
| Скорость разработки | Дольше | Быстрее на 20–35% |
| Доступ к API устройства | Полный | Почти полный |
| Подходит для маркетплейса | Да | Да (при грамотной архитектуре) |
Для большинства маркетплейсов Flutter — разумный выбор на старте: быстрее выйти на рынок, проще поддерживать одну кодовую базу. Нативная разработка оправдана, если у вас сложная работа с камерой, AR или специфическим железом.
Красные флаги при выборе подрядчика
За годы работы в разработке маркетплейсов мы видели одни и те же паттерны провальных сотрудничеств. Вот сигналы, которые должны насторожить:
- Называют цену без технического задания. «Приложение для маркетплейса — от 300 тысяч» — это не оценка, это угадывание. Нормальная команда сначала изучает задачу.
- Нет выделенного проект-менеджера. Если вы будете общаться напрямую с разработчиками без координатора — потеряете время и нервы.
- Отказываются показывать код предыдущих проектов или давать контакты клиентов. Хорошие подрядчики гордятся работой и готовы к референс-колу.
- Обещают сдать маркетплейс за 1–2 месяца. Реалистичный срок MVP маркетплейса — 3–5 месяцев при нормальной команде.
- Нет договора с фиксацией этапов и результатов. Работа «по-джентльменски» заканчивается спорами о том, что входило в scope.
Правильная последовательность запуска проекта
Если вы готовы разработка мобильного приложения начать с профессиональной командой, важно понимать, как выглядит нормальный процесс:
- Discovery-фаза (1–2 недели). Анализ бизнес-модели, конкурентов, целевой аудитории. Результат — техническое задание и роадмап.
- Прототипирование и UX-дизайн (2–4 недели). Кликабельный прототип, который можно тестировать с реальными пользователями до написания кода.
- Разработка MVP (8–14 недель). Только ключевые функции: регистрация, каталог, корзина, оплата, личный кабинет продавца.
- Тестирование и QA (2–3 недели). Функциональное, нагрузочное, тестирование на разных устройствах.
- Публикация и поддержка. Прохождение модерации App Store и Google Play, мониторинг ошибок, обновления.
Пропуск Discovery-фазы — самая частая причина переделок на 30–50% бюджета. Не соглашайтесь сразу прыгать в разработку.
Сколько стоит заказать мобильное приложение для маркетплейса
Диапазон широкий, и это честно — многое зависит от функциональности. Ориентиры по рынку РФ в 2024–2025 году:
- MVP маркетплейса (Flutter, базовые функции): 1,5–3,5 млн рублей, 3–5 месяцев;
- Полнофункциональная платформа с нативными приложениями: 4–10 млн рублей, 6–12 месяцев;
- Аутсорс в Юго-Восточной Азии: дешевле на 40–60%, но выше риски по качеству кода и коммуникации;
- Поддержка и развитие после запуска: 80–200 тыс. рублей в месяц в зависимости от объёма задач.
Не гонитесь за минимальной ценой. Переписать плохо спроектированное приложение обходится дороже, чем сделать правильно с первого раза.
Часто задаваемые вопросы
Можно ли заказать мобильное приложение для маркетплейса с фиксированной ценой?
Да, но только при наличии детального технического задания. Без него подрядчик либо закладывает большой буфер в стоимость, либо потом выставляет дополнительные счета за «неучтённые» задачи. Оптимальная схема для большинства проектов — фиксированная цена на Discovery-фазу и ТЗ, затем Time&Material или фиксированная цена на разработку по согласованному скоупу.
Сколько времени занимает публикация приложения маркетплейса в App Store и Google Play?
Google Play рассматривает новые приложения 1–3 дня, App Store — от 1 до 7 дней, иногда дольше при первой публикации или если приложение затрагивает финансовые операции. Закладывайте на этот этап 2 недели с учётом возможных замечаний от модераторов и итераций по их устранению.
Нужно ли разрабатывать отдельное приложение для продавцов или достаточно одного?
Зависит от сложности функционала продавца. Если продавцы только загружают товары и смотрят заказы — можно обойтись одним приложением с переключением роли. Если им нужен полноценный склад, аналитика продаж, чат с покупателями и управление акциями — отдельное приложение для продавца оправдано. Это решение стоит принимать на Discovery-фазе, а не в середине разработки.
Следующий шаг — обсудить ваш проект
Если вы уже понимаете, что вам нужно, или только формируете требования — команда Aris.Web готова разобраться вместе. Мы занимаемся разработкой мобильных приложений для маркетплейсов и знаем, где обычно теряются деньги и время. Позвоните нам по номеру +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — обсудим задачу, оценим сроки и предложим оптимальную архитектуру под ваш бюджет.