Ресторанная сеть делает 500 заказов в день через Яндекс Еду. Средний чек — 800 рублей. При комиссии агрегатора, скажем, 25% с каждого заказа платформе уходит 100 000 рублей в день — это условный пример для понимания масштаба, а не заявленная ставка Яндекс Еды. За год набегает 36 миллионов рублей. За эти деньги можно разработать собственное приложение, несколько лет его обслуживать — и всё равно остаться в плюсе. Но только если правильно посчитать.
За решением о собственном приложении доставки стоит не технология, а юнит-экономика. Правильный вопрос не «нужно ли нам своё приложение», а при каком объёме заказов комиссия агрегатора начинает проигрывать амортизированной стоимости собственного канала. Дальше в статье — формула расчёта, которую можно применить к своим цифрам, три реальных сценария для сети и честный разбор случаев, когда строить своё приложение рано.
Мы часто слышим от владельцев ресторанных сетей: хотим своё приложение, платим агрегаторам слишком много. Когда начинаем считать вместе, почти всегда оказывается, что точка окупаемости наступает раньше, чем ожидали. Но есть вторая переменная, которую обычно забывают: стоимость обслуживания приложения после запуска.
Рынок готовой еды растёт, и вместе с ним растёт давление комиссий на маржу операторов: в 2024 году рынок доставки готовой еды из ресторанов в России достиг 648,7 млрд рублей, увеличившись на 30,3% год к году, по данным РБК Исследований рынков. Чем больше сеть зарабатывает через агрегаторы, тем ощутимее становится их доля в выручке — и тем раньше имеет смысл посчитать альтернативу.
Три пути для ресторанной сети — агрегаторы, своё приложение или гибрид
Разговор про собственное приложение часто скатывается в крайность «агрегаторы плохие, своё приложение хорошее». В реальности есть три рабочих пути, и у каждого свои условия, при которых он оправдан.
| Путь | Что это | Когда подходит |
|---|---|---|
| Только агрегаторы | Вся доставка через Яндекс Еду и Broniboy | Старт, до 150 заказов в день, нет лояльной базы клиентов, нет ресурсов на разработку |
| Гибрид | Агрегаторы для привлечения новых клиентов, своё приложение для постоянных | 150+ заказов в день, есть база клиентов, которых можно перевести в прямой канал |
| Преимущественно своё приложение | Основной канал — фирменное приложение, агрегаторы остаются для новых клиентов | Сильный бренд, высокое удержание клиентов, 500+ заказов в день |
Агрегаторы хорошо работают на привлечение: человек открывает приложение, чтобы найти, где заказать, и видит вашу сеть среди тысяч других. Собственное приложение работает на удержание: там остаются клиенты, которые вас уже знают и возвращаются снова. Большинство успешных сетей используют оба канала одновременно, а не выбирают один вместо другого.
Частая ошибка — полностью уйти с агрегаторов сразу после запуска собственного приложения. Агрегаторы продолжают приводить новых клиентов, которых иначе сеть просто не увидит; собственное приложение работает с теми, кто уже сделал у вас хотя бы один заказ. Это разные задачи, и закрывать одним каналом обе не получится.
Насколько устойчиво работает система заказов независимо от того, через какой канал они приходят, — вопрос архитектуры, а не только выбора канала: подробнее об этом мы писали в статье «Онлайн-заказы без сбоев».
Что входит в «собственное приложение доставки» для сети
Приложение доставки для одной точки и для сети из 20 точек — принципиально разные продукты. Разница не в дизайне экранов, а в том, какие сетевые требования добавляют сложность и стоимость.
Единое управление меню с локальными вариациями. Изменение позиции или цены применяется сразу ко всем точкам, но с возможностью исключить отдельные локации — если в одном ресторане блюдо временно недоступно, а в остальных продаётся как обычно.
Геомаршрутизация к ближайшей точке. Приложение само определяет, какая точка обслуживает конкретный адрес доставки. Если в зону попадает сразу несколько точек, работает логика приоритизации: ближайшая, с наименьшей загрузкой или с лучшим расчётным временем доставки. Клиент не выбирает точку вручную — система делает это за него.
Единая программа лояльности на уровне сети. Баллы копятся через все точки, а не отдельно по каждой: клиент, заказавший в Минске, использует накопленные баллы в Гомеле. Технически это требует единого профиля клиента на уровне бренда, а не отдельной базы по каждому ресторану.
Раздельная аналитика по ролям доступа. Владелец сети видит сводные данные по всем точкам, управляющий конкретного ресторана — только свою точку. Без разграничения доступа по роли аналитика либо слишком закрыта, либо слишком открыта.
Интеграция с кассой каждой точки. Заказ из приложения должен автоматически попадать в кассовую систему — iiko, R-Keeper, Poster — без ручного переноса. Если в разных точках сети установлены разные кассовые системы, интеграцию приходится делать под каждую отдельно, и именно это чаще всего определяет итоговую стоимость проекта. Мы разбирали техническую сторону такой интеграции в статье «Технологии ресторана в 2026».
Хороший пример того, как эта логика масштабируется, — Foodclick, агрегатор для 660 ресторанов, который мы разработали: POS-интеграции покрывают три из четырёх распространённых типов касс, каждый ресторан видит только свои заказы, а QR-коды и брендинг у каждого партнёра свои. Принцип разграничения данных и интеграций в Foodclick тот же, что нужен собственному приложению сети, — просто на большем масштабе. Если строите архитектуру под такой рост, паттерны React Native для многокомпонентной экосистемы разобраны в статье «Архитектура FoodTech-приложения на React Native».
Разные кассы в разных точках сети — самая частая причина, по которой смета на приложение растёт вдвое.
Читать статьюФормула расчёта — когда своё приложение окупается
Дальше — конкретная формула, которую владелец сети может применить к своим числам прямо сейчас, без консультанта.
Для расчёта нужны три переменные: текущий объём заказов через агрегаторы в день, средний чек доставки и реалистичный процент постоянных клиентов, которые перейдут в собственное приложение при активном стимулировании.
Формула такая: ежегодная экономия равна количеству заказов в день, умноженному на средний чек, на комиссию агрегатора, на процент миграции и на 365 дней. Точка окупаемости в месяцах — это стоимость разработки, делённая на ежемесячную экономию на мигрировавшем объёме.
Разберём на иллюстративном примере — это не реальный кейс, а расчёт для понимания механики, свои цифры нужно подставлять отдельно. Сеть из 10 точек, 300 заказов в день, средний чек 700 рублей, условная комиссия агрегатора 25%: дневная комиссия составляет 300 × 700 × 0,25 = 52 500 рублей, годовая — 52 500 × 365 ≈ 19 миллионов рублей. При переходе 30% постоянных клиентов в собственное приложение экономия составит около 5,7 миллиона рублей в год. Если разработка стоит 4 миллиона рублей, окупаемость на мигрировавшем объёме — примерно 8-9 месяцев.
Простой расчёт выше не учитывает три статьи расходов, и без них решение о запуске будет неполным. Обслуживание приложения после запуска — обновления, поддержка, хостинг — это постоянные расходы, а не разовые. Маркетинг для стимулирования перехода — клиенты не переходят в новое приложение сами: нужны акции и скидка за первый заказ в собственном канале, и это тоже реальная статья бюджета. Потеря части нового трафика — агрегаторы приводят новых клиентов через поиск и каталог, а собственное приложение этого не делает и делать не должно.
Практический тест для владельца сети: если за последний месяц через агрегаторы шло больше 100 заказов в день и есть база постоянных клиентов, которых можно стимулировать перейти, — расчёт окупаемости, скорее всего, покажет, что собственное приложение выгоднее. Если большинство клиентов новые и приходят именно через агрегатор, сначала стоит поработать над удержанием, а к расчёту вернуться позже.
О том, как геосервисы и логика доставки влияют на сам выбор между агрегатором и собственным каналом, мы писали в статье «Что выбирают QSR — агрегаторы или собственную доставку»: реальный опыт ресторанов, которые уже проходили этот выбор.
Реальные результаты — что показывает практика
Формула выше — это теория. Дальше — что происходит, когда сеть действительно переводит часть заказов в собственный канал.
Yapoki — фирменное приложение доставки для фудтех-бренда с собственными ресторанами и сетью дарк-китчен. Формально это не франшиза, но прямое доказательство того же принципа: собственный фирменный канал ощутимо влияет на выручку, и этот принцип масштабируется на любую сеть. После запуска приложения 35% всех заказов компании пошли через него — без комиссии агрегатора на этой доле объёма — при более чем 200 заказах в день через мобильное приложение и свыше 20 000 загрузок. За тот же год выручка компании выросла с 2,1 до 3,1 миллиона долларов (+48%), количество заказов — на 29%, продажи — на 40%, по данным клиента из кейса. Для сети с сопоставимым объёмом заказов 35% в прямом канале — это существенная экономия на комиссии каждый месяц.
Foodclick показывает третий путь для тех, кто пока не готов к полноценному собственному приложению: платформа, которую мы разработали, объединяет 660 ресторанов с индивидуальным брендингом каждого партнёра и держит рейтинг 4,7 в App Store после пяти лет поддержки. Полноценным собственным приложением сети это не назвать — скорее брендированный агрегатор: клиент пользуется общей платформой, но видит бренд конкретного ресторана. Чему нас научил этот опыт при построении мультиресторанной платформы, мы разбирали в статье «7 уроков для тех, кто хочет создать SaaS-продукт для ресторанов».
Собственное приложение доставки — это не разовый проект, а операционный актив, который требует постоянного внимания: обновление меню, синхронизация с кассой, поддержка пользователей, продвижение. Сети, которые понимают это ещё до старта, — те, кто реально получает выгоду от такого канала, а не разочаровывается через полгода после запуска.
Сколько стоит и что влияет на цену
Дать один прайс на «приложение доставки для сети» невозможно — слишком много переменных. Но по уровням сложности ориентироваться можно.
| Уровень | Что включает | Ориентир по срокам |
|---|---|---|
| MVP для одной точки | Клиентское приложение (iOS и Android), оформление заказа, оплата, трекинг статуса, интеграция с одной кассой | 8-16 недель |
| Брендированное приложение для сети | Клиентское приложение и панель администратора, управление меню по точкам, зоны доставки, базовая лояльность, POS-интеграции | 16-24 недели |
| Полная IT-платформа для франшизы | Всё из уровня выше плюс разграничение доступа, аналитика по франчайзи, самостоятельное подключение новых точек | 24-40 недель |
| Обслуживание | Обновления, поддержка, хостинг, синхронизация меню | Постоянно |
Стоимость сильнее всего зависит от четырёх факторов: количества разных кассовых систем в сети (единая касса вроде iiko по всем точкам обходится дешевле, чем несколько разных систем в разных точках), количества точек и сложности аналитики по ним, наличия собственной курьерской службы вместо интеграции с готовыми сервисами доставки, и глубины программы лояльности — простое начисление баллов стоит совсем не так, как кросс-локационный профиль с персонализацией.
Если у сети одна-три точки со стандартными кассовыми системами и нет специфических требований, готовые SaaS-платформы обычно быстрее и дешевле на горизонте одного-двух лет. Кастомная разработка оправдана, когда SaaS-решение не поддерживает вашу кассовую систему или требования сети выходят за рамки типового продукта. Цены мы указываем по запросу — они слишком сильно зависят от конкретной конфигурации сети, чтобы давать один диапазон для всех.
Когда своё приложение — не лучший выбор
Собственное приложение доставки не универсальное решение, и честный ответ здесь важнее продажи.
Объём заказов пока слишком мал. Если через агрегаторы приходит меньше 100-150 заказов в день, экономия на комиссии вряд ли покроет стоимость разработки и обслуживания в разумный срок. Сначала стоит вырастить объём через агрегаторы, и только потом считать переход в собственный канал.
Нет лояльной базы клиентов. Если большинство находит вас через поиск в Яндекс Еде и не возвращается, собственное приложение не решит эту проблему — оно работает на удержание, а не на привлечение. В таком случае сначала имеет смысл заняться программой лояльности и качеством сервиса, а к своему приложению вернуться, когда появится база для миграции.
Нет ресурса на операционный менеджмент. Собственное приложение требует постоянного внимания: обновление меню, синхронизация с кассой, поддержка пользователей, продвижение для новых скачиваний. Без этого ресурса приложение быстро устаревает и перестаёт быть преимуществом.
Несовместимая кассовая система. Если касса не поддерживает интеграцию через API, стоимость проекта может вырасти настолько, что окупаемость станет сомнительной. Перед стартом стоит проверить интеграционные возможности текущей кассы — это быстрее и дешевле, чем узнать об ограничении в середине разработки.
Не уверены, поддерживает ли ваша касса нужную интеграцию?
Читать статьюИтог
- Собственное приложение доставки — это решение о юнит-экономике, а не о технологии: считайте точку окупаемости, а не «модно это или нет».
- Агрегаторы и собственное приложение решают разные задачи — привлечение новых клиентов и удержание постоянных — и чаще всего работают вместе, а не вместо друг друга.
- Формула расчёта окупаемости строится на трёх переменных: объём заказов через агрегаторы, средний чек и реалистичный процент миграции клиентов.
- В простой расчёт обязательно закладывайте стоимость обслуживания после запуска и маркетинг для стимулирования перехода — без них цифры окупаемости будут завышены.
- Для сети требования к приложению принципиально шире, чем для одной точки: единое меню, геомаршрутизация, кросс-локационная лояльность, разграничение аналитики и интеграция с кассой каждой точки.
- Разные кассовые системы в разных точках — главный фактор, который увеличивает стоимость и сроки разработки.
- Если через агрегаторы идёт меньше 100-150 заказов в день или ещё нет лояльной базы клиентов, строить собственное приложение рано — сначала стоит вырастить эти показатели.
