Мы разрабатываем мобильные приложения для курьерской доставки в ресторанах. Это не упрощённая версия клиентского приложения — это инструмент, работающий весь день в условиях плохой сети, одной рукой. Мы убираем лишние действия, чтобы курьер не терял время на лишние тапы. Наш опыт — 5+ лет и 50+ проектов в этой нише. Каждый проект мы начинаем с анализа сценариев курьера: как он открывает приложение, где находится, какие действия самые частые. Результат — приложение, которое не раздражает даже после 50 доставок.
Как отличить курьерское приложение от клиентского? — разработка мобильного приложения
Минимум действий на критическом пути. Принять заказ → подтвердить прибытие в ресторан → забрать заказ → навигация → подтвердить доставку. Это пять действий. Каждое — одна большая кнопка, никаких вложенных меню.
Экран «текущий заказ» — это всегда первое, что видит курьер при открытии приложения, без необходимости навигироваться. Реализуем через 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 или broadcast?
Два подхода:
Push-model: диспетчер или алгоритм назначает заказ конкретному курьеру → приложение получает push → курьер принимает или отклоняет. Простая реализация, подходит для небольшого парка курьеров.
Broadcast-model: заказ «разыгрывается» среди доступных курьеров в радиусе — кто первый принял, тот везёт. Требует WebSocket с состоянием «в торгах», таймаутом и fallback на следующего курьера. Реализуем через Laravel Broadcasting + Redis Pub/Sub.
| Характеристика | Push-model | Broadcast-model |
|---|---|---|
| Количество курьеров | до 10 | от 10 до 100+ |
| Простота реализации | низкая | средняя |
| Скорость назначения | высокая | средняя (конкуренция) |
| Алгоритм приоритизации | не нужен | PostGIS ST_Distance + рейтинг |
Broadcast-модель назначает заказы на 30% быстрее при парке более 50 курьеров.
Для ресторана с 5-10 курьерами достаточно push-модели. Для агрегатора с несотней курьеров — broadcast с алгоритмом приоритизации по дистанции.
Финансовый модуль курьера
Заработок за смену, история выплат, статус — в приложении. Наличный расчёт: курьер фиксирует получение наличных, система отражает задолженность перед рестораном. Выплаты через банковский перевод по расписанию или через СБП-выплаты (Tinkoff Business API). СБП-выплаты снижают комиссию до 0,7%.
Стек
Flutter 3.x + Bloc, Laravel 10 + WebSocket (Laravel Echo), PostgreSQL + PostGIS, FCM, Redis, Yandex MapKit или Google Maps SDK.
Процесс работы
- Анализ требований и проектирование архитектуры.
- Разработка прототипа и согласование UX.
- Реализация приложения и бэкенда.
- Тестирование на реальных устройствах.
- Деплой и обучение персонала.
| Этап | Длительность | Результат |
|---|---|---|
| Анализ | 1-2 недели | ТЗ и прототип |
| Разработка | 8-12 недель | MVP приложения |
| Тестирование | 2-3 недели | Отчёт о багах |
| Запуск | 1 неделя | Релиз в сторах |
Что входит в работу
- Аналитика и проектирование UX/UI с фокусом на курьерский сценарий
- Реализация приложения на Flutter с офлайн-режимом
- Разработка бэкенда на Laravel с PostGIS
- Интеграция с картами и платёжными системами
- Тестирование на реальных устройствах (включая бюджетные Android)
- Публикация в App Store и Google Play
- Обучение курьеров и поддержка после запуска
Типичные ошибки при разработке
- Не разрабатывать курьерское приложение отдельно от клиентского — они тесно связаны по событиям, но имеют принципиально разные UX-требования. Объединить их в один репозиторий Flutter (shared packages) — разумно; сделать один UI — плохая идея.
- Не тестировать на бюджетных Android в реальных условиях. Xiaomi Redmi 9 с MIUI 12, плохой LTE в центре города — именно на этом конфигурация ломается.
Сроки
MVP курьерского приложения с геолокацией, статусами доставки и маршрутизацией — от 12 до 18 недель. В связке с клиентским приложением и панелью ресторана — от 24 недель.
Стоимость рассчитывается индивидуально после анализа требований. Свяжитесь с нами для оценки вашего проекта — мы гарантируем прозрачность сроков и бюджета.