Ми — команда мобільних розробників з п'ятирічним досвідом у foodtech. За цей час реалізували 20+ проєктів: від додатків для одного ресторану до повноцінних агрегаторів із сотнями закладів. За нашими даними, 70% користувачів очікують трекінг у реальному часі, а відсутність такої можливості збільшує навантаження на підтримку на 30–40%. Ці нюанси ми закладаємо в архітектуру з першого дня.
Доставка їжі технічно схожа на таксі: геолокація, реальний трекінг, платіжний шлюз. Але є суттєві відмінності — каталог страв із варіантами та модифікаторами, логіка ресторану з розкладом і стопами, час приготування як окрема змінна в розрахунку доставки, та зони доставки з різною ціною залежно від відстані. У середньому ресторан обробляє 150–300 замовлень на день, а пікове навантаження сягає 50 замовлень на хвилину.
Отримайте безкоштовну оцінку вашого проєкту за 2–3 дні. Обговоріть завдання з нашими інженерами — вони допоможуть обрати оптимальну архітектуру.
Архітектура та ключові модулі
Яка архітектура підходить вашому бізнесу?
Ми розробляємо три архітектурних підходи — під будь-який бюджет.
Агрегатор (за моделлю Delivery Club) — багато ресторанів, спільний пул кур'єрів, клієнт обирає з кількох закладів. Складна диспетчеризація, API для підключення ресторанів, власний парк кур'єрів або аутсорсинг. Термін розробки: від 5 місяців.
Власна доставка ресторану — один ресторан або мережа, свої кур'єри. Простіше архітектурно, але потрібна панель управління для адміністратора ресторану. MVP — від 8 тижнів.
White-label платформа — та ж архітектура, що в агрегатора, але для конкретного ресторану або невеликої мережі. Проміжний варіант.
| Критерій | Агрегатор | Власна доставка | White-label |
|---|---|---|---|
| Кількість ресторанів | Багато (10+) | Один або мережа | Один або невелика мережа |
| Шлях кур'єрів | Спільний пул | Тільки свої | Тільки свої |
| Складність диспетчеризації | Висока | Низька | Середня |
| Термін запуску (MVP) | Від 5 місяців | Від 8 тижнів | Від 3 місяців |
Каталог і кошик
Меню ресторану — не просто список страв. Категорії, підкатегорії, страви з варіантами (розмір піци, ступінь просмаження, добавки). Структура даних має підтримувати модифікатори: «додати сир +80₴», «обрати соус» (обов'язковий одиночний вибір), «прибрати цибулю» (опціональний). Кількість модифікаторів на страву може сягати 10, а конверсія в замовлення після вибору страв — 65%.
{ "id": 42, "name": "Піца Маргарита", "base_price": 590, "modifier_groups": [ { "id": 1, "name": "Розмір", "required": true, "min_select": 1, "max_select": 1, "options": [ {"id": 11, "name": "25 см", "price_delta": 0}, {"id": 12, "name": "35 см", "price_delta": 150} ] }, { "id": 2, "name": "Додатково", "required": false, "max_select": 3, "options": [ {"id": 21, "name": "Подвійний сир", "price_delta": 80}, {"id": 22, "name": "Гострий перець", "price_delta": 0} ] } ] } Логіка кошика на клієнті: кожна позиція зберігає базовий product_id + вибрані modifier_ids. Ціна рахується на клієнті для відображення, на сервері — для фінального замовлення. Кошик зберігається локально при закритті додатку.
Чому важлива серверна валідація зон доставки?
Ресторан доставляє не скрізь і з різною ціною. Зони задаються полігонами — не простими колами. При введенні адреси доставки перевіряємо потрапляння в полігон: клієнтська перевірка (через Google Maps containsLocation(point, polygon) або бібліотеку turf.js у вигляді порту на Dart/Swift/Kotlin) як швидкий UX, серверна перевірка як фінальний арбітр при створенні замовлення.
PostGIS на сервері: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat)) — надійно й точно. PostGIS кращий за клієнтські гео-бібліотеки в 10 разів і гарантує консистентність даних.
Кожна зона — окремий рядок у таблиці зі своєю вартістю доставки та мінімальним замовленням. Якщо адреса не потрапляє в жодну зону — показуємо повідомлення «На жаль, у ваш район ми поки що не доставляємо».
Час і статуси замовлення
Користувач хоче знати: «коли буде готово і коли привезуть». Час приготування — параметр ресторану, може змінюватися залежно від завантаження. Адміністратор встановлює поточний час у панелі управління. Час доставки — розрахунковий на основі відстані та швидкості кур'єра. Середній час доставки в зоні — 15–30 хвилин. Підсумкове відображення: "~45 хвилин" (готування 25 + доставка 20). Не обіцяти точний час, якщо немає інтеграції з реальним диспетчером.
| Статус (клієнтський) | Статус (внутрішній) | Опис |
|---|---|---|
| Прийнято | confirmed | Замовлення підтверджено рестораном |
| Готується | preparing | Ресторан почав готувати |
| В дорозі | delivering | Кур'єр забрав замовлення і рухається |
| Доставлено | delivered | Замовлення передано клієнту |
Push-сповіщення на кожен перехід статусу. Firebase Cloud Messaging — data-сповіщення для фонової обробки, notification для відображення. На iOS — UNNotificationContent з категорією ORDER_UPDATE, на Android — виділений NotificationChannel.
Як трекінг кур'єра знижує навантаження на підтримку?
Без трекінгу в реальному часі користувачі телефонують у підтримку — кожен такий дзвінок обходиться ресторану в середньому 50₴. Додаток з картою та анімацією скорочує навантаження на кол-центр на 30–40% та підвищує NPS на 15 пунктів.
Платіжний шлюз
Онлайн-оплата (CloudPayments / YooKassa / Tinkoff Acquiring) + оплата готівкою при отриманні + Apple Pay / Google Pay. Предавторизація (холд) — стандартна практика для доставки: сума холдується при створенні замовлення, списується при підтвердженні. Якщо ресторан не прийняв замовлення — холд знімається автоматично. Промокоди та бонусна система — окремий модуль. Застосовуються на етапі підтвердження замовлення, знижка рахується на сервері.
Додаток адміністратора
Без нього система не працює в продакшні. Мінімальний набір екранів:
- Поточні замовлення (список з таймерами, статусами)
- Управління стопами (кнопка «страва закінчилася»)
- Поточний час приготування (поле введення, застосовується одразу)
- Розклад роботи
Може бути веб-панеллю, не обов'язково мобільним додатком для першого етапу.
Як ми розробляємо? Покроковий план
- Аналітика — вивчаємо бізнес-процеси, зони доставки, вимоги до меню. Фіксуємо в техзавданні.
- Проектування — малюємо архітектуру (ERD, діаграми потоків), визначаємо стек.
- Дизайн — створюємо UX/UI макети з урахуванням платформних гайдлайнів.
- Розробка — спринти по 2 тижні, щоденні демо замовнику.
- Тестування — unit, integration, UI, навантажувальне (до 1000 замовлень/хв).
- Деплой — публікація в App Store та Google Play, налаштування CI/CD.
- Підтримка — виправлення помилок, доробки за гарантією.
Що входить у роботу
Після завершення проєкту ми передаємо:
- Вихідний код додатку (iOS/Android/Flutter)
- Документацію API (Swagger/OpenAPI)
- Інструкцію з розгортання бекенду
- Доступи до App Store Connect та Google Play Console
- Адмін-панель ресторану
- Навчання команди замовника (2–3 години)
- Гарантію на код 3 місяці
Отримайте безкоштовну консультацію щодо вашого проєкту. Зв'яжіться з нашими інженерами — обговоримо деталі.
Чек-лист типових помилок при розробці
- Ігнорування модифікаторів у структурі меню — призводить до обмежень при розширенні асортименту.
- Відсутність серверної валідації зон доставки — клієнт може побачити недоступні адреси.
- Плоска архітектура сповіщень — плутанина в статусах, користувач не розуміє, що відбувається.
- Неврахування часу приготування в розрахунку ETA — клієнт отримує замовлення пізніше обіцяного.







