Разработка мобильного приложения для доставки еды (ресторан)
Приложение для курьера — это не упрощённая версия клиентского приложения. Это инструмент, который работает весь рабочий день, при плохом интернете, одной рукой, пока другая держит термосумку. Любой лишний тап или задержка экрана — это раздражение, которое накапливается за 50 доставок в смену.
Что определяет UX курьерского приложения
Минимум действий на критическом пути. Принять заказ → подтвердить прибытие в ресторан → забрать заказ → навигация → подтвердить доставку. Это пять действий. Каждое — одна большая кнопка, никаких вложенных меню.
Экран «текущий заказ» — это всегда первое, что видит курьер при открытии приложения, без необходимости навигироваться. Реализуем через AutoRoute (Flutter) с сохранением состояния: приложение помнит, что курьер в середине доставки, даже если он свернул его на 20 минут.
Офлайн-режим. В подвалах, в лифтах, в зонах слабого сигнала — соединение пропадает. Статусы доставки должны кешироваться локально (Hive или Drift) и синхронизироваться при восстановлении соединения. Если курьер нажал «Заказ доставлен» при отсутствии сети — это действие не должно потеряться.
Геолокация и диспетчеризация
Координаты курьера отправляются на сервер каждые 10-15 секунд во время активной доставки. На сервере (Laravel + PostGIS) это позволяет: показывать клиенту реальное положение курьера на карте, строить тепловые карты загрузки зон, считать реальное время в пути для ML-предсказаний.
На Android — foreground service с постоянным уведомлением «Доставка активна». На MIUI, One UI и других кастомных оболочках без этого приложение глушится системой через 10-15 минут. Это не особенность конкретного устройства — это архитектурное требование для курьерских приложений.
Маршрутизация: интеграция с Yandex Navigator SDK или Google Maps SDK для пошаговой навигации прямо в приложении — без переключения в сторонний навигатор.
Распределение заказов
Два подхода:
Push-model: диспетчер или алгоритм назначает заказ конкретному курьеру → приложение получает push → курьер принимает или отклоняет. Простая реализация, подходит для небольшого парка курьеров.
Broadcast-model: заказ «разыгрывается» среди доступных курьеров в радиусе — кто первый принял, тот везёт. Требует WebSocket с состоянием «в торгах», таймаутом и fallback на следующего курьера. Реализуем через Laravel Broadcasting + Redis Pub/Sub.
Для ресторана с 5-10 курьерами достаточно push-модели. Для агрегатора с несотней курьеров — broadcast с алгоритмом приоритизации по дистанции (PostGIS ST_Distance) и рейтингу.
Финансовый модуль курьера
Заработок за смену, история выплат, статус — в приложении. Наличный расчёт: курьер фиксирует получение наличных, система отражает задолженность перед рестораном. Выплаты через банковский перевод по расписанию или через СБП-выплаты (Tinkoff Business API).
Стек
Flutter 3.x + Bloc, Laravel 10 + WebSocket (Laravel Echo), PostgreSQL + PostGIS, FCM, Redis, Yandex MapKit или Google Maps SDK.
Типичные ошибки при разработке
Не разрабатывать курьерское приложение отдельно от клиентского — они тесно связаны по событиям, но имеют принципиально разные UX-требования. Объединить их в один репозиторий Flutter (shared packages) — разумно; сделать один UI — плохая идея.
Не тестировать на бюджетных Android в реальных условиях. Xiaomi Redmi 9 с MIUI 12, плохой LTE в центре города — именно на этом конфигурация ломается.
Сроки
MVP курьерского приложения с геолокацией, статусами доставки и маршрутизацией — от 12 до 18 недель. В связке с клиентским приложением и панелью ресторана — от 24 недель.
Стоимость рассчитывается индивидуально после анализа требований.