Розробка мобільного додатку для доставки їжі під ключ

Ми — команда мобільних розробників з п'ятирічним досвідом у foodtech. За цей час реалізували 20+ проєктів: від додатків для одного ресторану до повноцінних агрегаторів із сотнями закладів. За нашими даними, 70% користувачів очікують трекінг у реальному часі, а відсутність такої можливості збільшує навантаження на підтримку на 30–40%. Ці нюанси ми закладаємо в архітектуру з першого дня.

Доставка їжі технічно схожа на таксі: геолокація, реальний трекінг, платіжний шлюз. Але є суттєві відмінності — каталог страв із варіантами та модифікаторами, логіка ресторану з розкладом і стопами, час приготування як окрема змінна в розрахунку доставки, та зони доставки з різною ціною залежно від відстані. У середньому ресторан обробляє 150–300 замовлень на день, а пікове навантаження сягає 50 замовлень на хвилину.

Отримайте оцінку вашого проєкту за 2–3 дні. Обговоріть завдання з нашими інженерами — вони допоможуть обрати оптимальну архітектуру.

Архітектура та ключові модулі

Яка архітектура підходить вашому бізнесу?

Ми розробляємо три архітектурних підходи — під будь-який бюджет.

Агрегатор (за моделлю Delivery Club) — багато ресторанів, спільний пул кур'єрів, клієнт обирає з кількох закладів. Складна диспетчеризація, API для підключення ресторанів, власний парк кур'єрів або аутсорсинг. Термін розробки: від 5 місяців.

Власна доставка ресторану — один ресторан або мережа, свої кур'єри. Простіше архітектурно, але потрібна панель управління для адміністратора ресторану. MVP — від 8 тижнів.

White-label платформа — та ж архітектура, що в агрегатора, але для конкретного ресторану або невеликої мережі. Проміжний варіант.

Каталог і кошик

Меню ресторану — не просто список страв. Категорії, підкатегорії, страви з варіантами (розмір піци, ступінь просмаження, добавки). Структура даних має підтримувати модифікатори: «додати сир +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). Не обіцяти точний час, якщо немає інтеграції з реальним диспетчером.

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. Предавторизація (холд) — стандартна практика для доставки: сума холдується при створенні замовлення, списується при підтвердженні. Якщо ресторан не прийняв замовлення — холд знімається автоматично. Промокоди та бонусна система — окремий модуль. Застосовуються на етапі підтвердження замовлення, знижка рахується на сервері.

Додаток адміністратора

Без нього система не працює в продакшні. Мінімальний набір екранів:

• Поточні замовлення (список з таймерами, статусами)
• Управління стопами (кнопка «страва закінчилася»)
• Поточний час приготування (поле введення, застосовується одразу)
• Розклад роботи

Може бути веб-панеллю, не обов'язково мобільним додатком для першого етапу.

Як ми розробляємо? Покроковий план

1. Аналітика — вивчаємо бізнес-процеси, зони доставки, вимоги до меню. Фіксуємо в техзавданні.
2. Проектування — малюємо архітектуру (ERD, діаграми потоків), визначаємо стек.
3. Дизайн — створюємо UX/UI макети з урахуванням платформних гайдлайнів.
4. Розробка — спринти по 2 тижні, щоденні демо замовнику.
5. Тестування — unit, integration, UI, навантажувальне (до 1000 замовлень/хв).
6. Деплой — публікація в App Store та Google Play, налаштування CI/CD.
7. Підтримка — виправлення помилок, доробки за гарантією.

Що входить у роботу

Після завершення проєкту ми передаємо:

• Вихідний код додатку (iOS/Android/Flutter)
• Документацію API (Swagger/OpenAPI)
• Інструкцію з розгортання бекенду
• Доступи до App Store Connect та Google Play Console
• Адмін-панель ресторану
• Навчання команди замовника (2–3 години)
• Гарантію на код 3 місяці

Отримайте консультацію щодо вашого проєкту. Зв'яжіться з нашими інженерами — обговоримо деталі.