Разработка приложения доставки: диспетчеризация, курьеры, платежи и стоимость

Что входит в MVP приложения доставки

MVP полезен, когда закрывает один реальный цикл услуги. Для еды это заказ, оплата, приготовление, курьер и доставка. Для такси — заявка, подбор водителя, маршрут, статус поездки и оплата. Для сервисов по запросу — заявка, назначение провайдера, окно прибытия, статус работы и подтверждение.

Первая версия обычно включает:

• клиентский сценарий с адресом, заявкой, статусом и оплатой;
• сценарий курьера, водителя или провайдера с назначением, маршрутом, статусом и подтверждением выполнения;
• админ-панель для заказов, пользователей, провайдеров, зон, возвратов и поддержки;
• уведомления о важных изменениях статуса;
• аналитику по заявкам, отменам, опозданиям и неудачным платежам.

Если продукт именно про еду, отдельно посмотрите статью про ресторан и food delivery. Здесь мы говорим шире: доставка, такси, сервисы по запросу и операционная логистика.

Роли, которые меняют объем работ

Диспетчеризация и отслеживание — самая сложная часть

Практические гайды, например Leanware про разработку приложений доставки и Appscrip про стоимость on-demand delivery apps, сходятся в одном: сложность не в самой карте, а в правилах вокруг нее.

Кому первым показывать заказ? Что делать, если курьер отказался? Можно ли объединять два заказа? Может ли клиент поменять адрес? Что будет, если водитель потерял связь? Как поддержка вручную исправит статус? Именно эти вопросы формируют реальный объем разработки.

Карты и маршруты можно брать у готовых провайдеров, но они не придумывают операционные правила за бизнес. Поэтому работу с картами надо оценивать вместе с серверной частью, админ-панелью и поддержкой. Для этого полезна статья про серверную часть мобильного приложения.

Платежи, возвраты и выплаты

Приложения доставки часто похожи на маркетплейс по денежному потоку. Клиент платит, платформа может брать комиссию, курьер или провайдер получает выплату, а поддержка иногда делает частичный возврат. Поэтому тема связана с разработкой маркетплейса и ecommerce-приложением.

В Appfyl для планирования простые MVP обычно попадают в диапазон 1-1,5 млн рублей. Хорошие средние продукты часто попадают в диапазон 1,5-3,5 млн рублей. Крупные системы доставки, такси или сервисов по запросу с отслеживанием, несколькими ролями, выплатами, автоматизацией админ-панели и интеграциями могут уходить в 3,5-6 млн рублей.

Что сильнее всего влияет на стоимость

Оценка растет, когда нужны:

• отслеживание в реальном времени и работа геолокации в фоне;
• расчет маршрута, цены по расстоянию или времени прибытия;
• назначение, отказ и переназначение курьера;
• зоны, расписания, динамические цены или окна оказания услуги;
• выплаты провайдерам, возвраты, чаевые или комиссия платформы;
• админ-панель для поддержки, спорных ситуаций и ручных действий;
• интеграции с кассой, CRM, складом, автопарком или бухгалтерией.

Самый быстрый способ уменьшить объем — запуститься с ручной диспетчеризацией, небольшой зоной, простыми статусами и одной моделью оплаты. Автоматизацию лучше добавлять после первых реальных данных.

Как к этому подходит Appfyl

Appfyl начинает с карты операционного цикла: заявка клиента, назначение исполнителя, смена статусов, оплата, действие в админ-панели и ошибки. После этого мы решаем, что нужно автоматизировать с первого дня, а что можно временно делать руками.

Так MVP остается понятным для нетехнического владельца продукта. Вместо запроса "хочу приложение как Uber" лучше описать: кто делает заявку, кто ее выполняет, как считается цена, кто может отменить, как поддержка исправляет проблемы и что должна показывать админ-панель.

Для бюджета посмотрите стоимость разработки приложения или заполните калькулятор оценки Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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