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

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

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

Три типи систем

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

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

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

Для більшості стартапів на старті — другий або третій тип. Агрегатор вимагає окремого продукту для підключення партнерів, це подвоює обсяг роботи.

Каталог та корзина

Меню ресторану — не просто список блюд. Категорії, підкатегорії, блюда з варіантами (розмір піци, степінь прожарки, добавки). Структура даних повинна підтримувати модифікатори: «додати сир +80₽», «вибрати соус» (обов'язковий одиночний вибір), «убрати цибулю» (опціональний).

{
  "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) або port turf.js на Dart/Swift/Kotlin) як швидкий UX, серверна перевірка як фінальний арбітр при створенні замовлення.

PostGIS на сервері: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat)) — надійно та точно.

Кожна зона — окремена рядок в таблиці зі своєю вартістю доставки та мінімальним замовленням. Якщо адреса не попадає ні в одну зону — показуємо сообщення «На жаль, в ваш район ми поки не доставляємо».

Час приготування та доставки

Користувач хоче знати: «коли буде готово та коли привезуть». Час приготування — параметр ресторану, може мінятися залежно від навантаження. Адміністратор встановлює поточний час в панелі управління. Час доставки — розраховуючи на основі відстані та швидкості курʻєра.

Итоговое відображення: "~45 хвилин" (готовка 25 + доставка 20). Не обіцяти точний час, якщо нема інтеграції з реальним диспетчером.

Статуси замовлення та трекінг

Для доставки їжі статуси складніше ніж у таксі:

placed → confirmed → preparing → ready_for_pickup → courier_assigned → courier_picked_up → delivering → delivered

Клієнт бачить спрощену схему: «Прийнято» → «Готується» → «В дорозі» → «Доставлено». Між «В дорозі» та «Доставлено» — трекінг курʻєра на карті (той же WebSocket + анімований маркер).

Push-сповіщення на кожен перехід статусу. Firebase Cloud Messaging, data-сповіщення для фонової обробки, notification для відображення. На iOS — UNNotificationContent з категорією ORDER_UPDATE, на Android — виділений NotificationChannel.

Оплата

Онлайн-оплата (CloudPayments / YooKassa / Tinkoff Acquiring) + оплата готівкою при отриманні + Apple Pay / Google Pay. Предавторизація (холд) — стандартна практика для доставки: сума холдується при створенні замовлення, списується при підтвердженні. Якщо ресторан не прийняв замовлення — холд знімається автоматично.

Промокоди та бонусна система — окремий модуль. Застосовуються на етапі підтвердження замовлення, скидка рахується на сервері.

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

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

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

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

Стек

Тривалість проекту

MVP (одна платформа, один ресторан, базовий трекінг): вісім-дванадцять тижнів.

Повна платформа (iOS + Android, панель ресторану, агрегатор кількох закладів, аналітика): п'ять-вісім місяців.

Вартість розраховується індивідуально після аналізу вимог та декомпозиції на завдання.