Выбирает и получает
Каталог и фильтры, продавец в карточке, корзина, условия получения, история и статусы. Обращение в поддержку связываем с конкретным заказом.
13FOX / Для владельцев платформ
Разработка приложения маркетплейса
Мы создаём мобильное приложение, где покупатель выбирает товар и оформляет заказ, а продавец получает свою часть заказа и меняет её статус.
Связываем каталог, роли и заказы с сервером площадки. Серверные операции, модерацию и доработки админки фиксируем до оценки.
Оценить приложение маркетплейсаДля начала: один пользовательский сценарий, нужные системы и платформы.
Опыт мобильной торговли
Бакаев: приложение магазина, админ-панель и двусторонний обмен с 1С.
01 / Сквозной сценарий
Товары двух продавцов в корзине.
У каждого своя часть заказа.
Предлагаемый пример для площадки физических товаров: покупатель выбрал чашку у одного продавца и лампу у другого. До разработки согласуем, как общий заказ связан с его частями, оплатой и доставкой.
- 01
Выбор предложения
Покупатель видит товар, продавца, цену и условия получения. Если один товар предлагают несколько продавцов, в корзину попадает выбранное предложение.
- 02
Подтверждение на сервере
Сервер проверяет цену и доступное количество по согласованному источнику. Изменение цены или отсутствие товара показываем до подтверждения покупки.
- 03
Работа продавца
Каждый продавец получает только свои позиции и разрешённые данные. Подтверждает сборку и отгрузку; покупатель видит статус каждой части.
Лампа закончилась после добавления в корзину
Мы согласуем действие для этого случая: убрать позицию с подтверждением покупателя, предложить доступный вариант или остановить оформление. Остальная покупка и сумма меняются по правилам площадки. Сотрудник поддержки видит причину, состав заказа и доступное следующее действие.
02 / Доступ и публикация
Покупатель, продавец, оператор.
Для каждой роли — свои действия.
Ведёт свои предложения
Карточки, фотографии, цены и наличие — в разрешённом объёме. Заказы, подтверждение и отгрузка. Массовую загрузку каталога можно оставить в веб-кабинете, а срочные операции перенести на телефон.
Проверяет и разбирает
Очередь карточек, причины отклонения, жалобы и спорные заказы. Эти операции выполняются в админке. Уточняем, что уже есть и какой модуль нужно добавить.
Как карточка доходит до витрины
Предлагаем маршрут: продавец сохраняет черновик, отправляет на проверку, оператор публикует или возвращает с причиной. Продавец исправляет карточку и отправляет повторно. Для важных правок опубликованного товара отдельно задаём правило повторной проверки. Покупатель может пожаловаться на карточку; оператор разбирает жалобу и при необходимости блокирует нарушителя по правилам площадки.
Права проверяет сервер
Проверяем доступ к каждой карточке и заказу, включая запрос с чужим идентификатором. Продавец другого магазина не должен получить данные или изменить статус. Смена роли и отзыв доступа входят в приёмку.
Принцип проверки доступа к объектам API: OWASP ↗03 / Границы разработки
Первый релиз — один завершённый
путь от товара до статуса заказа.
Что предлагаем включить
- Вход и согласованные роли участников.
- Каталог, поиск и предложения продавцов.
- Корзину, оформление и выбранный способ оплаты.
- Статусы частей заказа, отмену и обращение в поддержку.
- Нужные мобильные действия продавца.
- Связь с модерацией и админкой через API.
Начинаем с выбранной категории, группы продавцов и модели доставки. Набор действий подтверждаем по вашему сценарию; он может быть уже или шире этого примера.
Зависимости серверной части
Что должно работать под приложением
Через API приложение получает данные и отправляет команды серверу. Для каждой цены, остатка и статуса называем систему-источник. Проверяем идентификаторы товаров и продавцов, права, создание заказа, подтверждение оплаты, отмену и ошибки обмена.
Комиссии, выплаты продавцам, взаиморасчёты, складская логика и полноценная админка требуют отдельного проектирования. Если платформы ещё нет, включаем создание нужных серверных функций в отдельный план и оценку.
Пуш-уведомление сообщает об изменении. Актуальное состояние заказа приложение получает с сервера при открытии.
Для физических товаров платёжный сценарий выбираем с учётом провайдера и правил магазина приложений. Apple выделяет такие покупки в пункте 3.1.3(e), а Google Play Billing предназначен для цифровых товаров. Платные функции продавца и цифровой ассортимент разбираем отдельно.
04 / Подтверждённая работа команды
В Бакаеве мы связали
мобильную покупку с учётом.
Мы разработали мобильный магазин с каталогом и заказами, админ-панелью и обменом с 1С. Помогли перенести локальную 1С в облако и связали системы через сервер синхронизации.
Сотрудник меняет фотографию в админ-панели — она обновляется в 1С. Покупатель оформляет заказ — остаток уменьшается в админ-панели и учётной системе. Изменения из 1С доходят до приложения.
Бакаев — магазин одного бизнеса. Этот опыт подтверждает работу с мобильным заказом и связанными данными. Для маркетплейса мы отдельно проектируем изоляцию продавцов, модерацию и правила частей заказа.
Посмотреть проект Бакаев ↗
05 / Состав оценки
Стоимость зависит от операций,
платформ и готовности сервера.
Просим один сценарий, пример товара и список систем. После разбора предлагаем состав первого релиза и оценку с допущениями. Если есть готовая платформа, сначала проверяем возможности её API.
Мобильная часть
iOS, Android или обе платформы; одно приложение с ролями либо отдельный клиент продавца; экраны, состояния ошибок и поддерживаемые устройства.
Сервер и интеграции
Готовые методы API и недостающие операции, источники каталога, платёжный сервис, доставка, уведомления и доступ к тестовой среде.
Запуск и сопровождение
Проверки, сборки, подготовка материалов для магазинов приложений, инфраструктура, сторонние сервисы и поддержка. Расходы и ответственность фиксируем отдельно.
Как мы ведём проект
- Разбираем заказ. Согласуем роли, источники данных и исключения; проверяем доступные API.
- Показываем прототип. Проходим покупку, действие продавца и разбор проблемы оператором. Утверждаем первый релиз.
- Собираем приложение. Подключаем согласованные серверные операции и проверяем работу на тестовых данных.
- Принимаем и передаём. Проверяем сценарии, передаём код и инструкции в составе договора, согласуем выпуск и поддержку.
Сценарии, по которым принимаем результат
- Один заказ с двумя продавцами: каждый видит свою часть; покупатель видит согласованные суммы и статусы.
- Цена изменилась или последняя единица уже продана: приложение показывает изменение до подтверждения.
- Ответ сервера потерян: при повторе сверяем созданный заказ; подтверждённая операция не повторяется в согласованном сценарии.
- Карточка отклонена: причина видна продавцу; исправление проходит повторную проверку.
- Сервер ещё не подтвердил оплату или отмену: покупатель видит, что операция обрабатывается, и может обратиться в поддержку. Итоговый статус сверяем с сервером.
- Прямой запрос к чужому заказу и отзыв доступа: сервер отклоняет запрещённые действия.
До договора
Вопросы о формате,
стоимости и передаче
Сколько стоит приложение маркетплейса?
Мы оцениваем согласованный состав: роли, экраны, платформы, готовность API и обработку ошибок. Отдельно показываем серверные доработки, платёжные и другие сервисы, публикацию и сопровождение. Для сравнения предложений нужен одинаковый сценарий заказа и перечень результатов; по одному списку экранов бюджеты сопоставить трудно.
Нужны ли два мобильных приложения?
Это зависит от работы продавца. Если основные операции — загрузка большого каталога и массовая правка цен, предлагаем веб-кабинет. Для фото товара, подтверждения заказа и статуса отгрузки может понадобиться мобильный доступ. Один клиент с переключением роли и два отдельных приложения сравним по сценариям, доступу и сопровождению.
Можно ли подключить приложение к готовой платформе?
Да, после проверки её API и правил доступа. На тестовой среде проверим карточку, предложение конкретного продавца, заказ и статусы. Если обязательной операции нет, включим доработку платформы в отдельный объём. Возможности конструктора, экспорт данных и ограничения лицензии проверяем до выбора решения.
Что проверить у подрядчика до договора?
Попросите показать работающий путь заказа и уточнить личный вклад команды в мобильную часть, сервер и админку. Сравните смету по ролям, исключениям и интеграциям. Зафиксируйте репозиторий, права на код, сторонние лицензии, инструкции сборки, доступы к аккаунтам и порядок поддержки: ответственного, порядок ответа на обращения и отдельные расходы.
Работаете с заказчиками из Москвы и Санкт-Петербурга?
Мы работаем с компаниями по России, включая Москву и Санкт-Петербург. В удалённом формате разбираем процесс с вашей продуктовой и технической командой, показываем сценарии на тестовой среде и согласуем приёмку. Для начала достаточно одного пользовательского сценария, систем и платформ.
Начнём с вашего заказа
Пришлите один сценарий,
системы и платформы.
Опишите, как продавец размещает товар и что происходит после покупки. Укажите, какие сервер, учёт, оплата и доставка уже работают. Мы предложим состав первого релиза, уточним зависимости и подготовим оценку.
Оценить приложение маркетплейсаДля первого разговора достаточно описания. Примеры товаров и заказов подготовьте без персональных и конфиденциальных данных.