Мы — команда мобильных разработчиков с пятилетним опытом в 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 месяцев |
Каталог и корзина
Меню ресторана — не просто список блюд. Категории, подкатегории, блюда с вариантами (размер пиццы, степень прожарки, добавки). Структура данных должна поддерживать модификаторы: «добавить сыр +$1–1», «выбрать соус» (обязательный одиночный выбор), «убрать лук» (опциональный). Количество модификаторов на блюдо может достигать 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.
Как трекинг курьера снижает нагрузку на поддержку?
Без трекинга в реальном времени пользователи звонят в поддержку — каждый такой звонок обходится ресторану в среднем $1–1. Приложение с картой и анимацией сокращает нагрузку на колл-центр на 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 — клиент получает заказ позже обещанного.
