Опыт dev.family: продукт, который отвоёвывает у агрегаторов маржу и данные — и инженерия, которая позволяет ему расти без переписывания.
Рынок, где по умолчанию выигрывает агрегатор
Онлайн-доставка еды в Саудовской Аравии — это уже не нишевая история, а рынок, который Grand View Research оценивает почти в $8 млрд по итогам 2024 года с прогнозом до $13 млрд к 2030-му (CAGR около 9%). Деньги большие, конкуренция плотная — и на этом рынке правила диктует агрегатор.
Проблема в том, что агрегатор — дорогой посредник. Комиссии крупных платформ в регионе доходят до 30–35%, а по ресторанным гайдам типичный коридор для Залива — 20–30% с заказа. Для ресторана это не просто статья расходов: это треть выручки с каждого доставленного блюда, которую забирает кто-то другой. Вместе с деньгами уходит и самое ценное — прямой контакт с клиентом и данные о нём: их получает платформа, а не бренд.
К нам пришёл крупный ресторанный холдинг из Залива — около 40 самостоятельных брендов, работающих в Саудовской Аравии, Кувейте и Великобритании, с планами выхода в США. За одним брендом может стоять несколько десятков ресторанов в одном только Эр-Рияде. Инфраструктура при этом была фрагментирована до предела: у каждого бренда — свои приложения, свои системы, свои процессы. Задача звучала амбициозно: собрать этот разрозненный ресторанный «космос» в один премиальный продукт, который не просто конкурирует с агрегаторами, а переопределяет опыт заказа еды.
Почему свой канал — это стратегия, а не «ещё одно приложение»
Идея собственного канала доставки в рознице звучит просто: убрать посредника. Но за ней стоят три разные бизнес-причины, и все три были важны клиенту.
Первая — маржа. Отказ от комиссий агрегаторов напрямую возвращает в бизнес те самые 20–35%. Мы уже разбирали, что выбирают QSR — агрегаторы или собственную доставку, и почему всё больше сетей строят собственный канал.
Вторая — владение данными и клиентом. Когда заказы идут через агрегатор, историей покупок, контактами и поведением аудитории владеет платформа. Свой канал разворачивает это: холдинг получает прямой контакт и собственную базу — а это фундамент для лояльности, ретеншена и персонализации. Индустрия давно называет это «ownership over aggregation»: собственные (first-party) заказы дают не только экономику, но и стратегический контроль над отношениями с гостем. О том, как превратить эти данные в деньги, у нас есть отдельный разбор — 6 способов увеличить маржу ритейла, используя данные, которые у вас уже есть.
Третья — опыт. И вот здесь начинается самое интересное. Просто «повторить агрегатор» недостаточно: если приложение холдинга ощущается так же, как любое другое, пользователю незачем переходить. Значит, свой канал должен быть не просто своим, а ощутимо лучше — премиальным.
Плюс поверх всего — требование масштаба. Продукт с самого начала проектировался под приток порядка 160–170 тысяч пользователей (собственная база холдинга плюс данные из агрегаторов на старте), под два языка (английский и арабский с RTL), мультивалютность и мультирегиональность.
Главный продуктовый вопрос: премиум «по ощущению» при чужих руках
Вот парадокс, вокруг которого крутился весь проект. Доставку физически выполняют третьи стороны — чужие кухни, чужая POS-система, сторонние курьеры. А ощущение премиальности нужно создать нам, в приложении, там, где мы контролируем каждый пиксель и каждый статус.
На этапе Discovery мы вместе с клиентом переводили размытые «премиальность» и «experience» в конкретные продуктовые решения. Работали по отлаженной методологии: спецификация продукта и UX-прототипы готовились параллельно, согласовывались и уходили прямо в задачи разработки. Прототипы делали не набросками, а высокодетальными — по прямому запросу клиента, чтобы их можно было показывать стейкхолдерам как готовый продукт. Объём оценивали через PERT с цветовой маркировкой уверенности (зелёный / оранжевый / красный), чтобы честно свести бюджет и сроки, а не пообещать невозможное. Кстати, о том, как правильно ставить задачу студии, у нас есть практичный чек-лист — как написать бриф для ресторанного приложения.
Из этого выросла продуктовая философия: не список-меню, а визуальный, эмоциональный выбор еды. Репозиционирование от «ещё одного агрегатора» к премиальному бренду со своим характером.
Дизайн как главный актив продукта
Есть данные, что визуальная подача напрямую влияет на решение о заказе — в еде мы «едим глазами» ещё до корзины. Поэтому дизайн стал одной из самых сильных частей проекта и, по признанию клиента, одним из главных активов.
Мы спроектировали более 150 уникальных экранов, объединённых в 31 пользовательский флоу, в тёмной премиальной эстетике с золотыми акцентами и крупной «вкусной» фуд-фотографией. Но премиальность — это не только красивая витрина. Это проработанность продукта целиком: для каждого сценария нарисованы состояния загрузки, пустые состояния, ошибки и успех — оплата не прошла, промокод применён или отклонён, товар недоступен, адрес вне зоны доставки. Хороший food-UX живёт именно в этих деталях, а не только на главном экране — и ровно на этих деталях чаще всего ломаются фудтех-приложения.
Жизненный цикл заказа спроектирован как полноценный конечный автомат: PENDING → CONFIRMED → PREPARING → READY → назначен курьер → DELIVERING → DELIVERED. У каждого статуса — свой экран, вплоть до карты с курьером, оценки заказа и водителя. Именно эта непрерывность превращает «чужую» доставку в цельный, управляемый опыт.
Поверх базового сценария заказа — премиальный и социальный слой: программа лояльности с балансом баллов, уровнями, привилегиями и стриками; гифтинг и реферальные коды; отзывы по конкретным блюдам, комментарии от шефа, лента контента и чат. Про то, как лояльность работает в мобильных приложениях, у нас есть отдельный обзор — программы лояльности в мобильных приложениях. Мультибренд и фудхоллы получили отдельные сценарии — заказ из фудхолла, мультибрендовая корзина, а также доставка, самовывоз и обслуживание за столом.
Всё это держится на зрелой дизайн-системе: 120+ компонентов с вариантами, цветовые токены, отдельная библиотека и полноценная проработка арабского интерфейса. Дизайн-система жила в каждом спринте как отдельный поток работы, а таблица переменных в Figma была единым источником правды для токенов. Почему такие вложения в дизайн окупаются, мы показали на другом кейсе — на что мы потратили 100 часов дизайна, чтобы в итоге спасти год разработки.
Live Activities в фудтехе: как одна фича решает три бизнес-проблемы
Read the articleНе приложение, а экосистема
Архитектурно это не одно приложение, а связанная платформа. В контур входят мобильное приложение и админ-бэкофис, наш серверный слой на Node.js, хаб мастер-данных, кастомная POS, агрегатор-хаб для развязки с кухнями, оркестратор last-mile-доставки, платёжный шлюз, каналы коммуникации, платформа лояльности, хранилище контента и аналитический контур — Datawarehouse, CRM и дашборды.
Наша зона ответственности — приложение, бэкенд и админка. И спроектировать её нужно было так, чтобы аккуратно встроиться в этот ландшафт и не создавать хаоса в данных. Для платформы, которая интегрируется с десятком внешних систем, это отдельная инженерная дисциплина — мы подробно разбирали её в материале про то, как связать POS, склад и финансы сети ресторанов, и в обзоре технологий ресторана в 2026: касса, KDS, лояльность и доставка как одна система.
Инженерия масштаба: мультитенантность и POS-агностичность
Это не франшиза и не доставка из одного ресторана, а потенциально десятки брендов, у каждого — своя кухня, меню, часы работы и геозоны. Мы спроектировали мультитенантную архитектуру с гибкой моделью «бренд → локация → филиал» и настраиваемым уровнем контроля на каждой сущности. Новые бренды и заведения добавляются конфигурацией, без переписывания приложения — а это ровно та проблема изоляции и масштабирования тенантов, которую в SaaS решают заранее, а не постфактум.
С похожими задачами масштаба мы сталкивались и раньше: как сеть ресторанов запускает одно приложение на 50 точек и как масштабировать франшизу, не потеряв управление.
Ключевое инженерное решение — вынести интеграцию с POS в отдельный слой. Мы не встраивали конкретную кассовую систему в код продукта, а описали единый внутренний интерфейс, за которым может стоять что угодно: кастомная POS клиента, агрегатор или тестовое окружение. Как сформулировал наш инженер:
Со стороны спецификации интерфейса всё остаётся неизменным — обращаемся ли мы к Deliverect или к чему-то другому.
По сути это классический anti-corruption layer — паттерн, который изолирует вашу модель данных от чужой и не даёт особенностям внешней системы «протечь» в ядро продукта. POS можно сменить, не переписывая приложение. Похожую развязку мы делали, когда объединяли 18 независимых iiko в единую систему управления франшизой. Для проекта на десятки брендов и с планами роста это не украшение архитектуры, а условие выживания.
Инфраструктура «по-взрослому» на Google Cloud
По прямому запросу клиента, который хотел держать инфраструктуру у себя, мы целиком построили проект на Google Cloud Platform. И пошли не привычным путём «контейнеры поверх облака», а задействовали управляемые сервисы по максимуму: managed PostgreSQL для данных, managed Redis под очереди (включая очередь уведомлений), Google Cloud Storage для файлов и изображений, балансировщики нагрузки — всё нативно связано внутри платформы, с раздельными стейджинг- и прод-окружениями.
Деплой настроили из нашего GitLab прямо в GCP, чтобы клиент мог управлять ресурсами из консоли. Локализацию и статический контент онбординга вынесли в remote config (Firebase) — чтобы менять их без релиза. Управляемые сервисы вместо самостоятельно поднятых кластеров — это меньше эксплуатационной нагрузки на команду и предсказуемое масштабирование под ожидаемый трафик. Как удержать стабильность потока онлайн-заказов при росте, мы разбирали в материале «Онлайн-заказы без сбоев». Сам мобильный стек — React Native, и почему это рабочий выбор для фудтеха, мы показали в разборе архитектуры FoodTech-приложения на React Native.
Интеграции, которые держат опыт вместе
- Кастомная POS клиента — источник меню, цен, модификаторов, изображений и стоп-листов. Через централизованную админку администратор подключает заведения и одной кнопкой синхронизирует данные.
- Deliverect — агрегатор-хаб, через который мы развязали приложение и операционную часть кухни.
- Nash — оркестратор last-mile-доставки: SaaS, в котором можно подключать и собственных водителей, и курьерские службы, и задавать логику назначения заказов. Мультирегиональный, как и сам продукт; в опыт заказа встроена страница трекинга курьера.
- Tap Payments — арабская платёжная система: онлайн-оплата и возвраты.
- Gameball — движок лояльности и геймификации: баллы, уровни, челленджи, кэшбэк, рефералы.
- social.plus — социальные функции: отзывы, оценки блюд, истории, лента.
- Firebase (remote config, push) и Google Maps / Places — карты, геокодирование, геозоны.
Челленджи и неочевидные решения
Умная смена адреса и ресторана. Когда десятки ресторанов одного бренда сталкиваются с реальностью разного наличия и цен, простой список перестаёт работать. Мы сделали решение, которого раньше не делали: при смене адреса или ресторана корзина сохраняется, а в списке заведений сразу видно, где какие позиции пропадут — без захода в каждый ресторан. Список фильтруется по доступности и сортируется по релевантности (сначала наличие, затем скорость доставки). Для самовывоза пользователь свободно меняет ресторан с сохранением корзины; для доставки мы маршрутизируем на ближайшую кухню, чтобы не создавать лишнюю нагрузку. Этот сценарий клиент отметил отдельно.
Маршрутизация мультибрендового заказа. Отдельная задача — как корректно передать заказ в POS, когда одна корзина охватывает несколько брендов в одной кухне.
Пробелы в API POS. В кухонной системе не хватало нужных эндпоинтов и вебхуков — например, обновления при уходе позиции в стоп-лист или уведомления о готовности заказа. Мы выстраивали интеграцию в условиях «сырого» API и проектировали обходные решения, чтобы пользователь этого не чувствовал.
Экономика на масштабе. Социальная платформа тарифицирует каждого гостя как оплачиваемого пользователя — при базе в 160–170 тысяч это грозило огромным счётом. Мы отдельно проектировали архитектуру так, чтобы отделить гостевой трафик от биллингового и защитить юнит-экономику продукта. На масштабе такие «мелочи» решают, сойдётся ли бизнес-модель вообще.
Арабский и RTL. Полная поддержка арабского с зеркалированием интерфейса закладывалась с первого дня. Это не «перевод строк», а двунаправленная вёрстка: зеркалирование layout, направление иконок и навигации, смешанный контент. Заложить это с самого начала на порядок дешевле, чем ретрофитить потом.
Что забрать из этого опыта
Если ваш бизнес — сеть или холдинг, который живёт на агрегаторах, вот короткий чек-лист из нашего опыта:
- Считайте не комиссию, а сумму комиссии и данных. Свой канал возвращает 20–35% маржи и, что важнее, отношения с клиентом.
- Премиум — это состояния, а не картинки. Ошибки, пустые экраны, статусы заказа и трекинг курьера делают «чужую» доставку цельным опытом сильнее, чем красивая витрина.
- Изолируйте POS с первого дня. Единый внутренний интерфейс (anti-corruption layer) означает, что смена кассовой системы не превращается в переписывание продукта.
- Мультитенантность и локализация — это фундамент, а не фича. Модель «бренд → локация → филиал», мультивалютность и RTL закладываются в архитектуру заранее, иначе каждый новый бренд или регион будет стоить как отдельный проект.
- Проверяйте юнит-экономику интеграций на вашем масштабе. Сервис, который на пилоте стоит копейки, при базе в сотни тысяч гостей может сломать всю модель.
Мобильное приложение для фудтеха: что о нём надо знать
Read the articleИтог
Такой продукт — это не «ещё одно приложение доставки», а премиальная фудтех-экосистема, спроектированная, чтобы расти вместе с холдингом: добавлять бренды, регионы и сценарии, не переписывая продукт. Путь от Discovery и дизайна, который полюбил клиент, до инженерно зрелой платформы с архитектурой, готовой к масштабу — ровно тот случай, где продуктовое, дизайнерское и инженерное мышление должны сработать вместе.
