Мы в Merehead строим такие системы на базе микросервисной архитектуры, поэтому дальше разбираем архитектуру, стоимость и реальные технические ловушки, а не общие рассуждения о том, «как хорошо иметь приложение».
Разработка приложения для доставки еды состоит из шести этапов:
- проектирование архитектуры и выбор модели синхронизации с ресторанами (API vs ручное обновление);
- разработка клиентского приложения с каталогом, корзиной и оплатой;
- разработка приложения курьера с real-time геолокацией и push-уведомлениями;
- сборка кабинета ресторана-партнера с разграничением ролей;
- настройка админ-панели, биллинга и системы лояльности;
- нагрузочное тестирование и подготовка инфраструктуры к пиковым часам (обед, вечер).
Архитектура: четыре роли, одна система
Любое приложение по типу GrubHub — это маркетплейс под ключ с тремя типами пользователей (клиент, курьер, ресторан) и одним оператором системы (админ). Ошибка, которую мы регулярно видим на этапе ТЗ, — команда проектирует эти роли как отдельные приложения с дублирующей логикой вместо единой продуктовой архитектуры с разными правами доступа.Мы решаем это так же, как на проектах с мультиролевой архитектурой в финтехе: один тип роли («партнёр») получает разные права через флаги вместо отдельных кабинетов, а заявки фильтруются по статусу вместо создания параллельных интерфейсов. Это снижает сложность на 100% там, где команда обычно закладывает overengineering ещё до старта разработки.
Под капотом такая архитектура опирается на асинхронную обработку задач: приём заказа, назначение курьера, обновление статуса — всё это события, которые не должны блокировать друг друга.
Challenge: очередь заказов под нагрузкой
Challenge: на одном из high-load проектов асинхронная обработка задач шла через web-сервисы, worker-ы и cron jobs, но фреймворк не поддерживал Kafka нативно, а некорректное закрытие сессий worker-процессов приводило к потере сообщений при рестартах — прямой аналог ситуации, когда очередь заказов «теряет» события при пересборке кластера.Solution: мы развернули трёхуровневую архитектуру (HTTP-сервисы, worker-ы для queue processing, cron jobs как отдельные Kubernetes deployments), интегрировали Kafka через кастомную библиотеку с явной реализацией graceful shutdown, а секреты доступа к брокеру вынесли в HashiCorp Vault с JWT-аутентификацией через единый Helm chart для всех сервисов.
Result: ноль потерянных сообщений при рестартах worker-процессов, унифицированный деплой, который позволяет добавлять новые микросервисы без операционного хаоса.
Для MVP без пиковых нагрузок Redis-очереди без Kafka закрывают 90% задач — Kafka подключаем, когда объём событий (заказы + geo-апдейты курьеров) начинает создавать backpressure.
Сколько стоит разработка и сколько это занимает времени
Прямых аналогов GrubHub в нашем портфеле оценок нет, поэтому даём ориентир на основе проектов сопоставимой сложности — маркетплейсов с мультиролевой архитектурой, геолокацией и real-time коммуникацией.| Уровень | Стоимость | Срок | Что входит |
| Basic | от $60,000 | 2–3 месяца | Backend + admin, web-app, один язык, гео на 1 страну, фиксированный/дистанционный расчёт доставки |
| Standard | от $72,000 | 2–3 месяца | + два языка, гео на 2 страны, native-приложения для курьера и клиента |
| Enterprise | от $90,000 | 2,5–3,5 месяца | Микросервисная архитектура, гео на 4+ стран, полная мультиязычность |
Отдельные модули считаются точечно и часто выпадают из первичной оценки: real-time чат между клиентом и курьером — от $5,000, интеграция платёжного шлюза — от $3,500, панель администратора с разграничением ролей (контент-менеджер, финансовый отдел, оператор поддержки) — от $1,500, кастомная CMS для управления меню и новостями — $8,000–$16,000. Детальный разбор стоимости разработки приложения для доставки еды помогает свести это в единый бюджет ещё на этапе брифа.
стоит разработка
приложение для доставки еды
Клиентское приложение: где реально теряются деньги
Каталог, корзина и оформление заказа — стандартный флоу, который есть в любом приложении доставки. Технически важная часть в другом: как каталог ресторана синхронизируется с реальной доступностью блюд. Есть два варианта — обмен по API с системой заведения или ручное обновление через админ-панель. Первый вариант требует интеграции на старте, но исключает ситуацию, когда клиент заказывает позицию, которой уже нет в наличии.Для данных, которые редко меняются — каталог блюд, карточки заведений — мы используем селективное кеширование в Redis с TTL. Персональные данные — корзину, статус заказа, баланс бонусов — кешировать нельзя: это создаёт ровно те баги с «неактуальным» заказом, из-за которых пользователи ставят приложению одну звезду.
Приложение курьера: real-time геолокация и матчинг
Модуль курьера — самая технически нагруженная часть системы, потому что здесь одновременно работают геолокация в реальном времени, push-уведомления о новом заказе и логика назначения (матчинга) курьера на заказ. Механика назначения похожа на диспетчеризацию в приложениях такси: система оценивает расстояние до ресторана, текущую загрузку курьера и ограничение по времени (SLA-таймер на принятие заказа), после чего отправляет push-уведомление.Challenge: устойчивость под пиковой нагрузкой
Challenge: при нагрузочном тестировании похожей real-time системы обнаружили, что база данных, Redis и приложение работали на одном сервере — под нагрузкой на исторические запросы (аналог: история заказов и маршрутов курьера) происходила взаимная деградация ресурсов, а прод-кластер оставался single-node, то есть один неконтролируемый cron job мог обрушить весь кластер через OOM.
Solution: мы вынесли базу данных на отдельный инстанс, добавили composite-индексы вместо full table scan на тяжёлых запросах и перевели периодические задачи (пересчёт ETA, обновление позиций курьеров) с голого cron на управляемые Kubernetes CronJobs с жёсткими CPU/RAM limits.
Result: система проходит нагрузочное тестирование без деградации 95-го перцентиля latency на критичных эндпоинтах и без cascade failures в часы пиковой нагрузки.
Готовое решение с этой логикой уже внутри — вариант для тех, кто хочет проверить бизнес-модель без разработки с нуля.
Кабинет ресторана-партнёра
Партнёр должен управлять меню, ценами и доступностью блюд без обращения в поддержку. Стандартный набор: изменение карточки заведения, добавление/удаление позиций меню, статистика по заказам, отчёты и сметы. Здесь снова работает принцип единой роли с разными правами: владелец сети ресторанов получает доступ ко всем точкам, менеджер одной точки — только к своей.На проектах с похожей мультиролевой логикой мы внедряли механику подтверждения между сторонами перед финализацией транзакции — это снижает число спорных ситуаций и разгружает поддержку. Для доставки еды прямой аналог — подтверждение получения заказа клиентом, которое закрывает транзакцию и запускает начисление бонусов.
Админ-панель, роли и безопасность
Разграничение ролей — не декоративная фича, а требование к архитектуре: главный администратор видит всё, контент-менеджер — только контент и меню, финансовый отдел — отчёты и биллинг, оператор поддержки — статусы заказов и чаты. Мы выносим секреты (доступы к платёжным шлюзам, API ресторанов) в HashiCorp Vault с JWT-аутентификацией — тот же подход, который используем в финтех-проектах, где нельзя хранить чувствительные данные в переменных окружения открытым текстом.Отдельный момент — данные банковских карт, которые приложение запрашивает при регистрации. Правильная архитектура не хранит их напрямую: платёжный шлюз токенизирует карту, а приложение хранит только токен. Это не опция, а требование PCI DSS, и его стоит закладывать в ТЗ до старта разработки, а не после первого инцидента.
Native или кросс-платформенное приложение
Курьеру и клиенту нужны разные приоритеты: курьеру — стабильная фоновая геолокация и push без задержек, клиенту — быстрый и приятный UI. Поэтому мы обычно рекомендуем нативную разработку (Kotlin/Swift) для курьерского приложения и рассматриваем React Native или Flutter для клиентского — там, где фоновая работа с GPS не критична. Разработка мобильных приложений для iOS и Android с нуля на двух нативных стеках дороже, но снимает риски с производительностью геолокации, которые кросс-платформенные решения регулярно упираются в системные ограничения фоновых процессов.| Критерий | Native (Kotlin/Swift) | Кросс-платформенный (React Native/Flutter) |
| Фоновая геолокация | Стабильна, полный доступ к системным API | Ограничена системными политиками энергосбережения |
| Скорость разработки | Ниже (два кодбейса) | Выше (один кодбейс) |
| Стоимость поддержки | Выше | Ниже |
| Рекомендация | Приложение курьера | Приложение клиента |
Масштабирование под пиковую нагрузку
Delivery-сервис не имеет равномерной нагрузки — трафик концентрируется в обеденное и вечернее время, а вне пиков инфраструктура простаивает. Асинхронная обработка через Redis и Kafka вместе с Kubernetes resource requests/limits решает именно эту задачу: система масштабирует worker-ы под пик и возвращается к базовому уровню ресурсов вне его, вместо того чтобы держать пиковую мощность круглосуточно. Это тот же принцип, который мы описывали для агрегаторов доставки еды с каталогом ресторанов — модель нагрузки там идентична.Что дальше
Приложение по типу GrubHub — это система с высокой конкуренцией за ресурсы в пиковые часы, а не витрина с каталогом и корзиной. Архитектурные решения, которые кажутся необязательными на этапе MVP — очередь сообщений, разграничение ролей, вынесение секретов в Vault — становятся дорогими, если добавлять их после запуска под реальной нагрузкой. Мы закладываем это на старте, поэтому оценка стоимости разработки мобильного приложения для бизнеса у нас включает архитектуру, а не только экран за экраном.FAQ
Сколько стоит разработать приложение как GrubHub с нуля?
Ориентир — от $60,000 за Basic-версию (backend, web-app, один язык, гео на одну страну) до $90,000+ за Enterprise с микросервисной архитектурой и мультиязычностью. Точная цифра зависит от набора модулей — real-time чат, платёжные интеграции и кастомная CMS считаются отдельно.
Сколько времени занимает разработка приложения для доставки еды?
На MVP уровня Basic/Standard — 2–3 месяца, включая discovery-фазу (техническая документация, архитектура, дизайн). Enterprise-версия с микросервисной архитектурой занимает 2,5–3,5 месяца.
Нужна ли системе учёта доставки еды отдельная разработка?
Если речь про внутренний учёт заказов, курьеров и смен — эта логика закрывается админ-панелью и модулем отчётности внутри самого приложения, отдельная система не требуется. Отдельная разработка нужна, только если заказчику нужна интеграция с внешней ERP или бухгалтерией.
Native или кросс-платформенная разработка лучше для приложения доставки?
Для приложения курьера мы рекомендуем нативную разработку из-за требований к стабильной фоновой геолокации. Для клиентского приложения кросс-платформенный подход (React Native/Flutter) снижает стоимость без потери качества.
Как рассчитывается стоимость доставки в приложении?
Два основных подхода: фиксированная цена по региону или динамический расчёт по расстоянию через геолокационное API. Второй вариант точнее, но требует интеграции с картографическим сервисом и логики пересчёта ETA в реальном времени.
