Разработка приложения для доставки еды и ресторана: что нужно, чтобы оно реально продавало

Своё приложение для доставки давно перестало быть «понтами» — это вопрос экономики. Агрегаторы вроде Яндекс Еды и Delivery Club забирают с каждого заказа ощутимую долю и не отдают заведению контакт клиента. Пока вы платите за каждого гостя комиссию, конкурент в той же выдаче перекупает его дешевле. При этом «приложение, как у соседа» само по себе заказы не приносит — приносит связка из правильных сценариев, оплаты в один тап и интеграции с кухней и кассой.

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

Почему агрегаторы — это дорого, и что меняет своё приложение

Агрегатор удобен на старте: он приводит трафик. Но как канал он устроен против вас в двух местах. Первое — комиссия. По рынку площадки забирают порядка 25–35% с заказа в зависимости от условий и города. Для общепита с его маржой это часто разница между «работаем в плюс» и «работаем на агрегатор». Второе — клиент вам не принадлежит. Гость, заказавший через Яндекс Еду, в следующий раз снова откроет Яндекс Еду и увидит там того, кто заплатил за место выше.

Своё приложение переворачивает три вещи:

• Маржа повторных заказов остаётся у вас. Привлечь гостя можно через агрегатор, но дальше его выгоднее «пересадить» в своё приложение, где нет комиссии площадки.

• Клиент привязан к бренду. Бонусы, история заказов, повтор любимого заказа в один тап — всё это держит гостя у вас, а не на маркетплейсе еды.

• Данные — ваши. Что заказывают, в какое время, как часто, какой средний чек по точкам — на этом строятся акции, меню и прогноз закупок.

Важно: своё приложение не отменяет агрегаторы. Грамотная схема — агрегатор как канал привлечения новых, своё приложение как канал удержания и повторных продаж с нормальной маржой.

Какие вообще бывают «приложения для доставки»

Под словом «приложение» владельцы часто имеют в виду очень разные вещи. Форматов три, и они отличаются по цене, скорости и тому, кому подходят.

На практике многие начинают с сайта или Telegram Mini App (быстро и недорого), а нативное приложение делают, когда база гостей уже собрана и понятно, что повторные заказы есть. Бэкенд (меню, заказы, оплата, интеграции) при этом общий, поэтому переход от одного формата к другому не означает «переписать всё заново», если архитектуру заложили правильно.

Минимальный рабочий состав: без чего нельзя запускаться

Не нужно сразу строить «убийцу Яндекс Еды». Нужен набор, который без дыр закрывает путь гостя от выбора блюда до получения заказа. Вот рабочий минимум.

Этого достаточно для запуска. То, что часто хотят «сразу», но спокойно живёт во втором этапе: геолокация курьера на карте в реальном времени, реферальная программа («приведи друга»), подписка на регулярные заказы (например, бизнес-ланчи), отзывы и оценки блюд, чат с поддержкой.

Что добавляют вторым этапом

Когда MVP работает и поток заказов пошёл, есть смысл достраивать то, что увеличивает частоту и чек:

• Отслеживание курьера на карте — снижает тревожность гостя и звонки.

• Уровни лояльности и геймификация — статусы, челленджи, «штампы» за заказы. Поднимают частоту визитов.

• Персональные акции по поведению — «вы давно не заказывали пиццу, держите промокод». Работает кратно лучше массовых рассылок.

• Подписки и предзаказы — регулярные доставки, бизнес-ланчи по расписанию.

• Мультибренд / dark kitchen — если у вас несколько концепций с одной кухни, в одном приложении можно показать их как отдельные витрины.

Главное, на чём проваливаются дешёвые «обёртки»: интеграции

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

Рабочее приложение интегрируется с тем, что у заведения уже есть:

• Система автоматизации общепита (iiko, r_keeper, Quick Resto). Заказ из приложения автоматически падает на кухню и пробивается по кассе. Меню и стоп-листы синхронизируются: закончилось блюдо — оно исчезает из приложения, и гость не закажет то, чего нет.

• Эквайринг и СБП, фискализация по 54-ФЗ. Оплата онлайн с корректным чеком — это не «приятная опция», а требование закона.

• Служба доставки. Назначение курьеров, расчёт зоны и стоимости доставки, интеграция со своей курьерской службой или агрегатором логистики.

• Аналитика. Выручка по точкам и по блюдам, средний чек, частота заказов, эффективность акций. Без этого вы не понимаете, окупается ли приложение.

Именно интеграция с iiko/r_keeper — то место, где разница между «сделали за 100 тысяч» и «сделали так, чтобы работало» становится очевидной. Это нужно закладывать в проект с первого дня, а не «прикручивать потом».

Разбор: что важно на реальном проекте

Когда мы в NorthCode переписывали мобильное приложение для пивной сети «Главпиво» в Санкт-Петербурге, задача звучала не как «сделайте красивое приложение», а как «сделайте так, чтобы оно зарабатывало и выдерживало нагрузку сети». Поэтому фокус был на трёх вещах: современная архитектура под нагрузку (старое приложение её не держало), программа лояльности с геймификацией (то, что возвращает клиента) и система аналитики продаж по точкам и клиентам (то, что даёт владельцу управляемость).

Вывод из таких проектов простой: «витрина» — это 20% ценности приложения для доставки. Остальные 80% — это связка с кассой, лояльность, которая реально работает, и аналитика, по которой принимают решения. Если подрядчик на первой встрече говорит только про дизайн и не спрашивает, какая у вас система автоматизации и как считается лояльность, — это плохой знак.

Частые ошибки, которые дорого стоят

На чём обжигаются чаще всего:

• Приложение без связи с кассой. Заказы переписывают руками. Через месяц приложением никто в заведении не хочет пользоваться.

• Сложная лояльность. Запутанные правила начисления бонусов = гость не понимает выгоды и не копит. Лояльность должна читаться за 5 секунд.

• Игнор стоп-листов. Гость заказал то, чего нет, заказ отменили — и потеряли клиента. Стоп-листы должны синхронизироваться автоматически.

• Запуск «всего и сразу». Пытаются сделать максимум функций на старте, бюджет и сроки уезжают, а половина возможностей не нужна. Правильно — MVP, потом расширение по данным.

• Нет аналитики. Приложение запустили, а считать эффект нечем. Деньги тратятся вслепую.

• Экономия на бэкенде. Дешёвый бэкенд не держит нагрузку в пиковые часы (вечер пятницы) — приложение падает именно тогда, когда заказов больше всего.

Сколько стоит и сколько занимает

Точную цифру даёт только аналитика под конкретное заведение и его процессы, но ориентиры по рынку такие:

Это ориентиры, а не прайс. Если кто-то предлагает «приложение для доставки под ключ за 50 тысяч за неделю» — почти наверняка это обёртка над сайтом без интеграции с кассой, которую придётся переделывать.

Как сэкономить разумно

Сэкономить можно без вреда для результата, если:

• Стартовать с MVP под один-два главных сценария (например, доставка + самовывоз с оплатой и базовой лояльностью), проверить спрос на повторные заказы и только потом достраивать.

• Начать с Mini App или сайта, а нативное приложение делать, когда есть лояльная база — так вы не платите за дорогой формат до того, как поняли, что он окупится.

• Переиспользовать бэкенд между форматами и платформами. Один раз сделанные каталог, заказы, оплата и интеграция с кассой работают и для сайта, и для Mini App, и для нативного приложения.

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

Часто задаваемые вопросы

Нужно ли и приложение, и сайт?

Да, обычно нужно и то, и другое, но не одновременно. Сайт нужен для SEO и быстрого заказа без установки, приложение — для удержания и повторных продаж. Часто стартуют с сайта или Telegram Mini App, а нативное приложение делают, когда есть лояльная база.

Можно ли не уходить с агрегаторов?

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

Что с интеграцией, если у нас iiko?

У iiko и r_keeper есть API, через который заказы из приложения автоматически попадают на кухню и кассу, а меню и стоп-листы синхронизируются. Это стандартная задача — главное заложить её в проект с самого начала.

Сколько времени гость пользуется приложением после установки?

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

Делать нативное приложение или хватит Mini App?

Если нужен быстрый и недорогой старт — Mini App. Если играете вдолгую, нужна иконка на экране, максимум удержания и push без ограничений — нативное. Часто делают и то, и другое на общем бэкенде.

Как считать, окупилось ли приложение?

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

Что в итоге

Приложение для доставки — это не «красивая витрина», а инструмент экономики: оно возвращает гостя, экономит комиссию агрегаторов и даёт данные для управления. Решают не картинки, а три вещи: интеграция с кассой (iiko/r_keeper), работающая программа лояльности и аналитика. Начинать почти всегда выгоднее с MVP или Mini App, а расширяться — по данным, а не по фантазиям.

Если у вас доставка или сеть заведений, а заказы всё ещё собираются вручную между телефоном, мессенджерами и агрегаторами — расскажите о задаче, разберём ваши процессы и предложим формат под объём и бюджет. Смежное: сколько стоит мобильное приложение, программа лояльности в приложении, мобильные приложения и Mini Apps.