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

Представьте, вы меняете цену на один бургер в сети из 40 точек. Через двадцать минут цена обновляется в 12 из 40. Часть управляющих звонят в головной офис. Остальные уже продали по десятку бургеров по старой цене. Это яркая (и очень банальная) иллюстрация того, что нельзя делать приложение для франшизы так же как приложение для одного ресторана и напихать туда несколько адресов/

Есть 4 принципа, которые должны быть соблюдены:

1. Меню должно управляться из одного центра, но цены и позиции на каждой точке могут быть свои. 
2. Гостя нужно узнавать в любой точке сети, а не заводить заново на каждой. 
3. У головного офиса и у управляющих должны быть разные права: кто что видит и кто что может менять. 
4. Приложение должно работать дальше, даже когда на точке падает интернет. 

Каждая из этих задач меняет привычный подход к разработке. Мы делаем системы для франшиз больше 10 лет, и закономерность простая: сети, у которых архитектура выстроена правильно уже на 20 точках, спокойно дорастают до 50 и 100 без переписывания. У кого нет — проходят болезненную переделку ровно тогда, когда силы стоило бы вкладывать в рост. Дальше разберём четыре главных решения, по которым мы понимаем, в какую группу попадёт сеть, сколько на самом деле стоит такое приложение и как мы ведём разработку на практике.

Чем разработка приложения для франшизы отличается от обычного ресторанного приложения

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

Максим Б.

CEO

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

Приложение для франшизы отличают от приложения для одной точки четыре вещи:

1. Меню. Есть общее меню сети, а на точках — свои правки: не только цены, но и состав позиций, часы работы, акции.
2. Гость. Гость принадлежит всей сети, а не отдельной точке. Это нужно заложить в самом начале — потом переделать дорого.
3. Права доступа. У ролей разный доступ к данным. Управляющий одной точки не должен видеть деньги другой.
4. Синхронизация. Данные должны жить в самом приложении и подгружаться на сервер в фоне, потому что интернет в зале часто подводит.

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

Разбираем на реальных примерах: где ломается контроль над меню, где теряется гость и что с этим делать технологически

Как масштабировать франшизу, чтобы не потерять управление

Читать статью

Решение №1 — централизованное меню с локальными ценами

Централизованное меню устроено в три уровня, а не одним файлом на всех: общее меню сети, региональные правки и правки конкретной точки. У каждого уровня свой хозяин и свои права. Если их не разделить, получается одно из двух: либо центр теряет контроль над брендом, либо управляющий не может подстроить меню под свой район.

Несколько вещей, которые мы поняли только когда вывели это в работу:

• Цена-исключение хранится отдельно, с привязкой к точке и сроком действия (таблица price_override с location_id и effective_date). Это отдельная запись «со своим сроком», а не просто поле внутри позиции.
• Доступность по точкам — это отдельное расписание. Позиция в Москве доступна с 11:00, в Казани — с 10:00. Здесь речь не про часовые пояса, а про график работы.
• Обновление меню не должно стирать правки точек. Когда центр меняет общее меню, локальные правки обязаны сохраниться — мы дописываем поверх, а не заменяем целиком.

Ошибка, которую делают почти все, — хранить меню одним документом, а правки точек делать его копиями. Поменяли общее меню один раз — и за день 40 копий разъехались. Мы делаем иначе: точки наследуют общее меню и меняют только то, что нужно именно им (это и есть inheritance-модель — наследование вместо копий).

На недавнем проекте (сеть фастфуда), первая же синхронизация меню вскрыла ровно эту проблему. Позиции приходили из кассы сети (iiko) без цены или с прочерком, выгрузка тянула только часть размеров, а ценовые категории на уровне франшизы были настроены неправильно. Это был не баг приложения — просто цены по точкам не проверили до синхронизации. А ещё та же сеть хотела цены на доставку примерно на 15% выше, чем в зале. Это классическая локальная правка, и сделать её можно двумя путями: отдельными позициями в кассе или наценкой в самом приложении. От этого выбора зависит поведение всех будущих акций и отчётов — поэтому структуру меню мы продумываем на этапе архитектуры, а не настраиваем потом на коленке. Здесь же приложение стыкуется с кассой, так что как меню синхронизируется с POS важно не меньше, чем устройство самого приложения.

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

Как мы объединили 18 независимых iiko в единую систему управления франшизой

Читать статью

Решение №2 — единый ID гостя по всем точкам

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

Узнать гостя можно тремя способами, у каждого свои плюсы и минусы для сети:

• Телефон — самый простой. Минус: путаница с префиксом +7 и дубли при смене номера.
• Email — надёжно, но гость не всегда помнит, какой адрес указывал.
• QR / карта лояльности — работает, только если карта с собой, зато удобнее всего прямо в зале.

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

Уже пользуетесь кассой и лояльностью, но между точками они не дружат? Честно скажем, что нужно, чтобы свести гостя в одно целое

Максим Б. CEO

Запланировать встречу

В наших проектах для сетей чаще всего стартуют с телефона и единой программы лояльности на всю сеть: одна ставка начисления, один потолок списания, одна реферальная программа. Баллы и стоп-листы при этом синхронизируются между кассой, приложением и POS в реальном времени. На одном таком проекте сами правила были простыми (баллы 1:1, списание до 20%, рефералка включена). Сложным было другое: чтобы баланс вёл себя одинаково, заказывает гость самовывоз на одной точке или доставку с другой. Именно это и даёт единый ID гостя — но только если заложить его до открытия второй точки.

Для Beerpoint, сети магазинов разливного пива, мы сделали приложение лояльности на едином ядре, которое держит синхронизацию по всей сети. За это время сеть выросла со 189 до 211 точек, у приложения порядка 99,7 тыс. установок на Android (на декабрь 2025). Гость у нас привязан к бренду, поэтому баллы из одного магазина узнаются в любом другом — вот как зрелая лояльность на сеть выглядит на практике. А для розничной сети John Dory мы собрали единую программу лояльности на все магазины сети (200+ точек) — баллы, скидки и пуши в одном приложении. Если вы начинаете с малого, функции лояльности в приложении для одной точки — разумный первый шаг.

Разбираем отдельно с примерами из реальных проектов

Программы лояльности в мобильных приложениях

Читать статью

Решение №3 — права доступа (RBAC) для сети

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

Три уровня прав обязательны:

1. Корпоративный администратор — может всё: меню, цены, брендинг, аналитика по всем точкам, управление аккаунтами управляющих.
2. Управляющий точки — только своя точка: расписание, наличие позиций, локальные акции в рамках правил сети. Данных других точек не видит.
3. Сотрудник / кассир — только приём и просмотр заказов своей точки. Меню — в режиме «только смотреть».

Деталь, которую мы не пропускаем: права должны проверяться на сервере (на уровне API), а не только в интерфейсе. Частая ошибка — спрятать кнопки в приложении, но оставить открытым сам запрос к серверу. Кто знает, как этот запрос устроен, тот его и отправит. То же с базой данных: управляющий не должен видеть выручку другой точки даже случайно. Для этого база сама не отдаёт чужие строки (это называется row-level security), а не «отфильтруем где-нибудь в коде».

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

Максим Б.

CEO

И ещё правило, на котором мы теперь настаиваем с первого дня: у данных по меню и ценам на стороне сети должен быть один ответственный, а права на правку — разнесены по ролям. На одном проекте главный риск был даже не во взломе, а в добром намерении: одна массовая правка могла переписать меню и цены сразу по всем точкам. Никакого злого умысла — достаточно одного лишнего права. Мы перевели правки каталога на работу через тестовый пример с контролем доступа, прежде чем что-то попадёт в боевую сеть. На одной точке слабые права — мелкая неприятность. На сети — способ положить меню всех магазинов одним кликом. Это те же принципы прав доступа из B2B-продуктов, что работают и для франшизы, где многоуровневый доступ — норма.

Решение №4 — работа в офлайне для точек с плохим интернетом

Интернет в ресторане — часто один Wi-Fi на всех: касса, планшет официанта, музыка и гостевой вай-фай делят его между собой. В час пик он проседает. Если приложение работает только онлайн, при каждом обрыве работа встаёт. Для одной точки это терпимое неудобство. Для 50 точек сразу — это сбой, который всплывает по сети несколько раз в неделю.

Есть два подхода, и разница между ними решает всё:

• Сначала сервер (online-first). Приложение работает через интернет, а при обрыве показывает то, что успело сохранить. Беда в том, что новые заказы и баллы в офлайне не записываются — и гость уходит без начисленных баллов.
• Сначала приложение (offline-first). Все данные хранятся прямо в приложении, а синхронизация с сервером идёт в фоне. Новые заказы складываются в очередь и уходят на сервер, как только связь вернётся.

Когда мы делаем синхронизацию для сети, каждый раз всплывают три вопроса:

1. Чья версия победит. Если одну и ту же позицию поменяли и в центре, и в приложении на точке во время обрыва — что оставить? Обычно для меню и цен безопаснее, чтобы побеждала версия сервера.
2. Баллы в офлайне. Гость хочет списать баллы, а связи нет. Баланс известен из памяти приложения, но он мог измениться на другой точке. Решение: даём списать сразу, а потом сверяем, когда связь вернётся.
3. Сколько влезет в очередь. Если точка с большим трафиком три часа без связи — это несколько тысяч операций. Под это нужно заранее закладывать место в памяти и порядок отправки.

К сожалению, мы видели, что происходит, когда данные не хранятся в приложении: заказы, не дошедшие до сервера; баллы, которые пропали; управляющие, которые всё сводят руками на закрытии смены… 

Максим Б.

CEO

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

Сколько на самом деле стоит приложение для франшизы — и почему white-label не всегда дешевле

Готовые решения (white-label и SaaS) кажутся дешевле ровно до того момента, когда вы начинаете подгонять их под свою сеть. Тут цена резко растёт, а гибкость — нет. Кастомная разработка дороже на старте, зато вы владеете кодом и масштабируетесь без оглядки на условия вендора.

Три варианта, для ориентира (не оффер):

• Учётные системы для сети (iiko / iikoChain, r_keeper, Quick Resto, 1С:Общепит): подписка на точку или на сеть. Закрывают склад, фискализацию, бэк-офис. Но не дают брендированное приложение для гостя и свою лояльность.
• Готовое приложение доставки (white-label) (FoodPicasso, Frontpad, Smartomato): быстро и под вашим брендом. Минус: единое меню с правками по точкам почти не настраивается, а гость привязан к точке, а не к сети. Лояльность часто докручивают надстройками (Mindbox, Plazius, UDS), но единый номер гостя на всю сеть и глубокая интеграция зависят от связки с кассой.
• Кастомная разработка: ориентировочно от нескольких миллионов рублей за первую фазу и выше — зависит от объёма. Полное владение, масштабирование без роялти, но нужна команда поддержки или партнёр.

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

Кастом окупается при 15+ работающих точках с планом расти за 50, при лояльности на 10 000+ участников, при потребности в сквозной аналитике по сети или при интеграции со старыми и нестандартными кассами (старые версии r_keeper, 1С, самописные кассы), которые готовые сервисы поддерживают плохо. И он не нужен, если у вас 3–10 точек, обычная лояльность, нет старой кассы и нет планов экспансии — тогда FoodPicasso или Frontpad закроют 95% задач за долю цены, и вы сэкономите серьёзные деньги. Эта честность важна, потому что ошибка в любую сторону стоит дорого.

Разбираем, из чего складывается настоящая стоимость нестабильности: SLA, MTTR и сколько стоит одна минута простоя на сети из 40 точек

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

Читать статью

Как это построить — процесс разработки приложения для франшизы

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

Этап 1 — Аудит архитектуры (2 недели). Смотрим текущую кассу, лояльность и данные. На выходе — одна простая вещь: какие данные относятся ко всей сети, а какие к конкретной точке. Это технический аудит со схемой данных на выходе, а не обычный созвон-знакомство.

Этап 2 — Ядро данных и API (3 недели). Проектируем наследование меню, единый сервис гостя и матрицу прав (RBAC) — до того, как пишем экраны.

Этап 3 — MVP: админка + 1 точка (6–8 недель). Делаем админку для управления меню и приложение для одной пилотной точки. Офлайн — пока в базовом виде.

Этап 4 — Пилот: 3–5 точек (4 недели). Расширяемся на несколько точек. Тут всплывают реальные нестыковки в синхронизации и правках меню, и мы дорабатываем права по тому, как управляющие работают на самом деле.

Этап 5 — Масштабирование (постоянно). Подключаем остальные точки и интегрируемся с кассой. Следим за сбоями синхронизации и сверкой баллов.

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

Реальные сроки, из нашей практики: от аудита до запуска на первой точке — 3–4 месяца. От первой точки до 20 — ещё 2–3 месяца, если архитектура правильная. Это цифры из работы, а не из красивой презентации. Перед стартом полезно знать, на что смотреть при выборе подрядчика и как подготовить техзадание, чтобы аудит стартовал с твёрдой почвы.

Шаблон брифа из 6 разделов и 5 ошибок, которые раздувают бюджет ещё до старта разработки

Как написать бриф для ресторанного приложения: шаблон и типичные ошибки

Читать статью

Ключевые выводы

• Приложение для франшизы — это в первую очередь про архитектуру. Четыре решения (наследование меню, единый ID гостя, права на уровне сервера, работа в офлайне) определяют, вырастете вы спокойно или будете всё переделывать на 15-й точке.
• Меню — это три уровня (сеть → регион → точка), а не копии. Копии разъезжаются за день.
• Делайте гостя «общим на всю сеть» с первого дня. Прикрутить это потом — три месяца возни с дублями и потерей истории.
• Проверяйте права на сервере и в базе, а не только в интерфейсе. И не забудьте про уровень франчайзи.
• Стройте приложение так, чтобы оно работало в офлайне. Иначе при обрывах тихо теряются заказы и баллы.
• Кастом оправдан примерно от 15 точек с активной лояльностью и старой кассой. Ниже — берите готовое, это дешевле и быстрее.
• Закладывайте 3–4 месяца до запуска на первой точке и +20–30% к стартовой цене на «правильную» архитектуру. Это экономит в 2–3 раза больше на несостоявшихся переделках.

FAQ