Ми розробляємо мобільні застосунки для кур'єрської доставки в ресторанах під ключ. Це не спрощена версія клієнтського застосунку — це інструмент, що працює весь день в умовах поганої мережі, однією рукою. Ми прибираємо зайві дії, щоб кур'єр не витрачав час на зайві тапи. Наш досвід — 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-модель: диспетчер або алгоритм призначає замовлення конкретному кур'єру → застосунок отримує push → кур'єр приймає або відхиляє. Проста реалізація, підходить для невеликого парку кур'єрів.
Broadcast-модель: замовлення «розігрується» серед доступних кур'єрів у радіусі — хто перший прийняв, той везе. Потребує WebSocket зі станом «в торгах», таймаутом та fallback на наступного кур'єра. Реалізуємо через Laravel Broadcasting + Redis Pub/Sub.
| Характеристика | Push-модель | Broadcast-модель |
|---|---|---|
| Кількість кур'єрів | до 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
- Навчання кур'єрів та підтримка після запуску
Також входить: налаштування CI/CD, документація API, техпідтримка 3 місяці. Оцінка проекту — безкоштовно. Пишіть — ми розрахуємо точну вартість за 2 дні.
Типові помилки при розробці
- Не розробляти кур'єрський застосунок окремо від клієнтського — вони тісно пов'язані за подіями, але мають принципово різні UX-вимоги. Об'єднати їх в один репозиторій Flutter (shared packages) — розумно; зробити один UI — погана ідея.
- Не тестувати на бюджетних Android у реальних умовах. Xiaomi Redmi 9 з MIUI 12, поганий LTE в центрі міста — саме на цій конфігурації ламається.
Терміни та вартість
MVP кур'єрського застосунку з геолокацією, статусами доставки та маршрутизацією — від 12 до 18 тижнів, ціна від $15 000. У зв'язці з клієнтським застосунком та панеллю ресторану — від 24 тижнів, від $30 000. Економія до 20% при замовленні комплекту.
Вартість розраховується індивідуально після аналізу вимог. Зв'яжіться з нами для оцінки вашого проекту — ми гарантуємо прозорість термінів і бюджету.