Приложение для доставки еды: когда оно окупается и как устроено

Рынок большой и продолжает расти: доставка готовой еды в России — 788,3 млрд ₽ по итогам 2025 года с ростом 21% год к году, в 2026-м ожидают ещё около 13%. Вопрос не в спросе, а в том, кому достаётся маржа.

Ориентир практиков: около 200 заказов в день. Ниже этого порога приложение почти всегда не окупается — не потому, что оно плохое, а потому, что стоимость разработки и поддержки делится на слишком малый поток.

Признаки, что пора:

• Высокая доля повторных заказов. Клиенты возвращаются — значит есть кого переводить в свой канал.
• Свой бренд и лояльность. Люди приходят за вашей едой, а не за скидкой платформы.
• Несколько точек и стабильное меню. Есть что синхронизировать и куда масштабировать.
• Заметная доля заказов с агрегаторов. Комиссия уже измеряется сотнями тысяч в месяц.
• Планы на подписку и программу лояльности. Механики, которые в чужом приложении не построить.

Обратный случай: одно заведение, десятки заказов в день, поток нестабильный. Здесь приложение станет расходом с отложенным эффектом, а деньги полезнее вложить в кухню и в маркетинг на агрегаторах.

Между «только агрегаторы» и «своё приложение» есть промежуточные варианты, и они закрывают заметную часть задач.

Адаптивный сайт с оформлением заказа. Открывается по ссылке, не требует установки, обновляется мгновенно. Для первого своего канала обычно достаточно.

PWA. Тот же сайт, но устанавливается на телефон с домашнего экрана, работает офлайн в части сценариев и умеет пуш-уведомления на Android. Дешевле нативного приложения и не требует прохождения модерации сторов.

Заказ через мессенджер. Бот с меню и корзиной: быстро запускается, подходит для небольшого потока, но плохо масштабируется на сложное меню и не даёт нормальной аналитики.

Что теряете без приложения: удобство повторного заказа в два касания, полноценные пуши на iOS, место на домашнем экране и часть механик лояльности. Разумный путь — начать с сайта или PWA, накопить базу повторных клиентов и переходить к приложению, когда поток оправдывает бюджет.

Главная причина, по которой смета удивляет: заказчик считает одно приложение, а разрабатывать нужно три интерфейса с разной логикой.

Экраны в доставке одинаковые у всех, разница в деталях, которые видно только на реальном потоке.

Скорость до корзины. Гость, который заказывал у вас раньше, должен повторить заказ в два касания. «Повторить последний заказ» — самая используемая кнопка в зрелых приложениях доставки.

Честное время. Не «30–40 минут» из настроек, а расчёт по загрузке кухни и наличию курьеров. Завышенное обещание стоит дороже, чем реальные 55 минут, названные сразу.

Понятный статус. Принят, готовится, у курьера, рядом. Без этого поддержка получает звонки «где мой заказ», а гость — впечатление, что о нём забыли.

Адрес и зона доставки. Проверка адреса до оплаты, а не после; понятная граница зоны и стоимость доставки, которая не меняется на последнем шаге.

Отсутствующие блюда. Стоп-лист должен работать до момента оплаты. Отмена блюда после оплаты — самая дорогая ошибка в отзывах.

Логистическая часть в 2026 году стала главным ограничением рынка: рост собственной доставки замедлился до 15–20% именно из-за дефицита курьеров и стоимости логистики. Софт эту проблему не решает, но заметно смягчает.

Назначение заказов. Ручное распределение работает до десятка курьеров, дальше нужен автоматический подбор по зоне, загрузке и времени готовности блюд — та же задача, что матчинг в приложении для такси.

Время приготовления против времени в пути. Курьер, приехавший на десять минут раньше готовности, простаивает; приехавший позже — везёт остывшее. Согласование этих двух сроков даёт больше эффекта, чем оптимизация маршрута.

Батчинг. Объединение двух-трёх заказов в один выезд снижает стоимость доставки, но требует контроля: третий заказ в связке почти всегда приезжает холодным.

Работа без сети. Приложение должно принимать статусы офлайн и досылать их при появлении связи, а не терять действия курьера.

Прозрачность оплаты. Курьер видит, сколько заработал за смену и за конкретный выезд. Это влияет на удержание сильнее, чем интерфейс.

Техническая часть, которая ломается чаще всего, и её недооценивают в каждой второй смете.

Меню живёт в кассовой системе ресторана, а не в приложении. Значит нужна синхронизация: блюда, цены, модификаторы, фотографии, категории, доступность по времени (завтраки до 12:00), доступность по точкам. Обмен должен быть двусторонним — изменение в кассе видно в приложении, а заказ и его отмена видны в кассе.

Отдельная сложность — стоп-листы. Блюдо закончилось на кухне, и об этом должны узнать все каналы за секунды, а не в следующий цикл обмена. Задержка в пять минут означает несколько оплаченных заказов, которые придётся отменять и возвращать деньги.

Модификаторы добавляют комбинаторику: «без лука», «двойной сыр», «средняя прожарка» — каждая опция влияет на цену и на состав. Их нельзя хранить в приложении отдельно от кассы, иначе цены разъезжаются, и гость видит одну сумму, а касса печатает другую.

Практическое требование к архитектуре: приложение не должно быть единственным источником данных о меню. Источник истины — касса, приложение показывает её состояние и умеет корректно вести себя, когда оно меняется в момент оформления заказа.

Список того, с чем придётся связываться, известен заранее — и именно он определяет большую часть сметы.

• Кассовая система. iiko или r_keeper — отраслевой стандарт: меню, цены, стоп-листы, передача заказа на кухню, статусы готовности.
• 1С. Управленческий и бухгалтерский контур: выручка, себестоимость, номенклатура.
• Платежи. Эквайринг, СБП, привязка карты для повторных оплат, возвраты.
• Карты и геокодирование. Яндекс.Карты или 2ГИС: адреса, зоны доставки, маршруты, отслеживание курьера.
• Уведомления. Пуши и СМС о статусах заказа; на устройствах без сервисов Google нужен альтернативный канал доставки.
• Аналитика и лояльность. События заказа, воронка, бонусы и промокоды.
• Курьерская служба. Если доставка на подряде — обмен заказами и статусами с её системой.

Кассовые системы мы не внедряем — интегрируемся с ними, и это важное разделение ответственности: настройка iiko или r_keeper остаётся за их партнёрами, наша часть начинается на границе обмена. Из практики: подключение к кассе почти всегда занимает больше времени, чем планируется, потому что часть данных приходится согласовывать с тем, кто настраивал систему до нас.

Место, где проект часто спотыкается на приёмке, потому что до неё об этом никто не думает.

Оплата при оформлении. Эквайринг и СБП: СБП дешевле по ставке, эквайринг привычнее гостю и позволяет привязать карту для повторных заказов в одно касание.

Частичные отмены и возвраты. Блюдо отменили из стоп-листа, курьер не доехал, гость отказался — все эти сценарии должны корректно проходить по деньгам и по чекам, а не разбираться вручную бухгалтерией.

Фискализация. Чек должен уйти гостю, а операция — в учёт. Схема зависит от того, кто продавец: сам ресторан, сеть или площадка. Этот вопрос решается на старте, потому что он влияет на архитектуру платежного контура.

Оплата курьеру. Наличные и терминал у курьера всё ещё существуют, и их нужно учитывать в сверке смены.

Чаевые и промокоды. Мелочи, которые всегда просят добавить и которые задевают и платежи, и учёт.

Соблазн сделать «как в Яндекс Еде» — верный способ потратить бюджет до запуска. Реалистичная первая версия закрывает один сценарий: гость заказал, кухня получила, курьер привёз.

В MVP обычно входят: каталог с актуальным меню и модификаторами, корзина и оформление с проверкой адреса и зоны, оплата онлайн, синхронизация меню и стоп-листов с кассой, статусы заказа и пуши, простая админка для менеджера, базовая аналитика заказов.

Что откладывают без потери смысла: программа лояльности и бонусы, подписки, персональные рекомендации, отслеживание курьера на карте в реальном времени, батчинг заказов, мультибренд и несколько городов, отзывы и рейтинги блюд. Как отделить необходимое от желаемого — в материале про MVP.

Отдельно про сроки: первая версия под обе платформы плюс админка — это обычно три-четыре месяца, если кассовая система одна и меню стабильно. Приложение под ключ с дизайном, разработкой и публикацией в сторах укладывается в этот же срок, потому что часть каркаса не пишется с нуля.

Самая частая причина, по которой приложение не окупается: его сделали, а трафика в нём нет. Перевод клиентов — отдельная работа, и её планируют вместе с разработкой, а не после релиза.

Вложение в заказ. Листовка или карточка в каждом пакете с понятной выгодой: не «скачайте наше приложение», а «в приложении этот заказ стоил бы на 15% меньше». Работает, потому что попадает к человеку, который уже вам заплатил.

Разница в цене и ассортименте. В своём канале нет комиссии, поэтому часть этой экономии можно честно отдать гостю: цена ниже, доставка дешевле, порция больше, позиции, которых нет на площадках.

Механики, которых у агрегатора нет. Накопительные бонусы, подписка на обеды, любимый заказ в один тап, предзаказ на конкретное время. Гость остаётся не из лояльности, а из удобства.

QR на месте и в чеке. Для заведений с залом и самовывозом это самый дешёвый канал установки.

Пуши без злоупотребления. Уведомление о готовности заказа и о статусе доставки ждут; три акции в день выключают уведомления, а потом и удаляют приложение.

Чего делать не стоит: одномоментно уходить с агрегаторов. Они остаются каналом привлечения новых гостей, а свой канал забирает повторные заказы — в этой связке и получается экономика, а не в противостоянии.

Смету двигают пять факторов, и по каждому есть вопрос, который стоит задать себе до разговора с подрядчиком:

Считать приложение каналом привлечения. Оно удерживает и удешевляет повторные заказы, но новых гостей приводят маркетинг и агрегаторы.

Запускать приложение при малом потоке. До нескольких сотен заказов в день экономика не сходится, и деньги полезнее вложить в кухню и продвижение.

Сделать меню в приложении отдельно от кассы. Цены и стоп-листы разъезжаются в первую неделю, а гость получает отмену после оплаты.

Забыть про курьерское приложение. Клиентская часть красивая, а курьер отмечает статусы в мессенджере, и половина данных о доставке теряется.

Не проработать возвраты. Частичные отмены и возвраты руками разбирает бухгалтерия — по нескольку часов в неделю с первого месяца.

Обещать нереальное время доставки. Завышенные ожидания дают отзывы хуже, чем честные 55 минут, названные при оформлении.

Три шага, которые не требуют подрядчика. Первое — посчитать вклад заказа в двух каналах: через агрегатор с его комиссией и через свой канал с доставкой, эквайрингом и маркетингом. Второе — посмотреть долю повторных заказов: именно она показывает, есть ли кого переводить в приложение. Третье — выяснить, что умеет ваша кассовая система: какие данные она отдаёт, как часто и через какой интерфейс.

С этими цифрами понятно, начинать ли с PWA или сразу с приложения, и какой состав первой версии закроет ваш основной сценарий без лишнего.