Розроблення мобільного додатку для курьєра доставки їжі
Додаток курьєра — це не спрощена версія клієнтського. Це інструмент, який працює весь рабочий день, при поганому інтернету, однією рукою, поки інша держить термосумку. Будь-який зайвий тап або затримка екрану — це роздратування, яке накопичується за 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-модель: диспетчер або алгоритм призначає замовлення конкретному курьєру → додаток отримує push → курьєр приймає або відхиляє. Проста реалізація, підходить для малого парку курьєрів.
Broadcast-модель: замовлення "розіграється" серед доступних курьєрів у радіусі — хто перший прийняв, той везе. Потребує 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+ тижні.
Вартість розраховується індивідуально після аналізу вимог.