Как мы разработали кастомное мобильное приложение для сети ресторанов «МиМи» с интеграцией iiko

Автор статьи: Максим Новиков

Как провести аудит ресторана: пошаговая инструкция, виды и цели.

Полный цифровой контур: сайт + приложение + лояльность + доставка

Клиент: сеть ресторанов «МиМи», Москва

Период: 2024–2025

Команда: RESTOCRM (направление кастомных проектов, ранее — Mehanika.digital)

Интеграция: iikoTransport API + iikoCard API

Публикация: апрель 2025 — App Store и Google Play

Исходная ситуация: сайт есть, доставка работает, но нет мобильной экосистемы

Сеть ресторанов «МиМи» уже имела:

• собственный сайт с индивидуальным дизайном
• работающую доставку
• систему iiko
• активную клиентскую базу

Первым этапом сотрудничества стала интеграция сайта с iiko.

Мы подключились на уровне API, реализовали:

• корректный обмен через iikoTransport API
• синхронизацию меню
• передачу заказов
• интеграцию бонусной программы через iikoCard API

После успешного запуска сайта клиент поставил следующую задачу:

Создать полноценное мобильное приложение, которое объединит доставку, самовывоз, лояльность и офлайн-рестораны в едином цифровом контуре.

Задачи проекта

1. Сохранить фирменную айдентику бренда
2. Обеспечить высокую скорость работы приложения
3. Объединить сайт, приложение и iiko в единую систему
4. Реализовать единый интерфейс для всей сети
5. Сделать процесс разработки прозрачным и управляемым

Важно: это был не «шаблонный запуск», а полноценный кастомный проект.

Проект начался не с дизайна, а с UX-анализа рынка

Большинство мобильных проектов начинают с макетов.

Мы начали с исследования.

Анализировали 10 лучших приложений доставки:

• Яндекс.Еда
• Delivery Club
• BonApp
• BB Delivery
• и другие российские и зарубежные сервисы

Разобрали:

• регистрацию
• авторизацию
• корзину
• оплату
• бонусные сценарии
• удержание
• ошибки
• микровзаимодействия

Все данные свели в сравнительную таблицу (см. скрин с Miro-доски).

Выделили:

✔ обязательные фичи

✔ UX-решения, повышающие конверсию

✔ ошибки, которых нужно избегать

И только после этого сформировали техническое задание.

Архитектура проекта: сначала стратегия, потом код

До начала разработки был сформирован:

• детальный таймлайн
• этапы
• спринты
• точки контроля
• бюджет
• график релизов

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

Каждые 14 дней клиент получал рабочую версию продукта.

Прозрачность — ключевой элемент кастомной разработки.

(См. скрин: Miro-таймлайн + Telegram-коммуникация)

Выбор технологии: React Native vs нативная разработка

Мы провели технический сравнительный анализ:

Для «МиМи» оптимальным решением стал React Native.

Это позволило:

• запустить MVP за 3 месяца
• одновременно готовить iOS и Android
• сократить бюджет без потери качества

Разработка: от прототипа до релиза

Этап 1. Техническое задание

На основе UX-анализа сформирована карта экранов и пользовательских сценариев.

Этап 2. Прототипирование

Создан кликабельный прототип в Figma:

Прототип позволил:

• пройти путь пользователя до оплаты
• выявить блокеры
• согласовать логику
• сократить количество переделок

Важно: мы всегда создаём рабочий прототип, а не просто дизайн-макеты.

Этап 3. Разработка MVP

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

Реализованы:

• каталог
• карточка блюда
• корзина
• профиль
• бонусная система
• раздел ресторанов
• фильтры
• сторис

Тестирование:

• TestFlight
• Google Play Internal Testing

Этап 4. Публикация

Первые сборки — уже на втором месяце.

Финальный релиз — апрель 2025.

Приложение опубликовано в:

• App Store
• Google Play

Ключевые решения в приложении

Интеграция с iikoTransport API

• меню
• заказы
• статусы
• синхронизация

Интеграция с iikoCard API

• бонусная программа
• начисление
• списание
• грейды

Профиль пользователя

• бонусная карта
• история заказов
• QR-код
• избранное

Раздел «Рестораны»

• фильтрация по формату
• живая музыка
• банкеты
• мероприятия

Stories-лента

Общая + индивидуальная для каждого ресторана.

TabBar-навигация

• Доставка
• Рестораны
• Условия
• Профиль

Результаты

• Публикация в App Store и Google Play
• Более 1000 установок за первые 6 месяцев
• Рост активной базы пользователей
• Увеличение повторных заказов
• Полная синхронизация сайта, приложения и iiko

Главное достижение — создан единый цифровой контур.

Лучшие практики RESTOCRM, применённые в проекте

✔ каждый проект начинается с UX-анализа

✔ всегда создаётся кликабельный прототип

✔ спринтовая модель разработки

✔ прозрачная коммуникация

✔ тестирование совместно с клиентом

✔ инженерный подход к интеграциям

Итог

Проект «МиМи» — пример того, как кастомная разработка может сочетать:

• эстетику бренда
• инженерную архитектуру
• прозрачный процесс
• бизнес-результат

RESTOCRM подходит к каждому проекту как к сервису в хорошем ресторане:

важен не только результат, но и сам процесс.

Хотите запустить собственное приложение?

Если вам нужно:

• кастомное мобильное приложение
• интеграция с iiko
• программа лояльности
• единая экосистема сайт + приложение
• QR-заказ в зале
• аналитика и рост повторных продаж

Оставьте заявку — рассчитаем экономику проекта и предложим оптимальную архитектуру.

Готовое решение или кастомная разработка: что выбрать ресторанному бренду и почему

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

«Нам взять готовое решение или делать кастом?»

И в этом месте многие совершают ошибку: воспринимают выбор как «дешёвое/дорогое» или «быстро/долго».

На деле выбор другой:

готовая платформа — это скорость и проверенная логика,

кастом — это бренд, уникальные процессы и свобода архитектуры.

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

Когда ресторану подходит готовое решение

Готовые платформы (в том числе решения РЕСТОЦРМ / RESTOCRM) нужны тогда, когда главная цель — быстро запуститься, стабильно работать и не тратить годы на “изобретение велосипеда”.

Это лучший путь, если вы:

1) Хотите быстро выйти в онлайн и проверить гипотезу

Например:

• запуск доставки с нуля
• запуск нового бренда (dark kitchen)
• тестирование нового района
• тестирование спроса на самовывоз

В этом случае вам важнее не “идеальная уникальность”, а:

• скорость запуска
• стабильная работа
• понятная экономика
• и возможность быстро вносить изменения без команды разработчиков

2) Хотите минимизировать риски и стоимость владения

Кастом — это не только “разработка”, но и:

• поддержка
• обновления
• устранение ошибок
• безопасность
• интеграции
• тестирование после обновлений iOS/Android или кассы

Готовая платформа снимает значительную часть этой нагрузки.

У вас есть продукт, который развивается, обновляется, поддерживается, а вы не держите внутри компании отдельный IT-отдел ради “сайта доставки”.

3) Вам подходят типовые бизнес-процессы

Большинство ресторанов работают по схожей логике:

• каталог → корзина → оплата → доставка/самовывоз
• бонусы → начисление/списание
• пуши и рассылки
• сегменты базы
• простые акции и промокоды

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

4) Вы хотите “продукт”, а не “проект”

Это важное различие.

Проект — это когда “сделали и забыли”, а потом всё ломается и никто не знает, кто виноват.

Продукт — это когда система обновляется, исправляется, развивается.

РЕСТОЦРМ / RESTOCRM — это как раз продуктовый подход: платформа как сервис.

А для ресторана это означает стабильность.

Когда ресторану нужен кастом (и почему готовое не подходит)

Кастомная разработка нужна не потому, что “красиво”, а потому что:

у вас есть уникальность, которую нельзя упаковать в шаблон,

и она важна для бизнеса.

Это тот случай, когда дизайн и процесс — часть продукта, а не “обёртка”.

Кастом оправдан, если:

1) Бренд — это стратегия, а не логотип

Есть рестораны, у которых позиционирование — ключевой актив:

• премиум
• дизайнерские концепции
• сильная эстетика
• эмоциональный бренд
• “стиль жизни”, а не просто доставка

У таких проектов типовой интерфейс убивает половину смысла.

И тогда кастомное приложение становится продолжением бренда — как интерьер, кухня и сервис.

Именно поэтому «МиМи» — кастомный проект. Там важно было не “просто заказы”, а сохранить атмосферу бренда в цифровом продукте.

2) Нужны нетиповые сценарии и процессы

Например:

• особая логика доставки
• сложные типы меню и сборные блюда
• индивидуальные акции по событиям
• нестандартная лояльность
• механики подписок или предзаказов
• сеть ресторанов с разными форматами внутри одной экосистемы
• специфические сценарии “Рестораны / афиши / события / банкеты”

Когда бизнес-процессы не укладываются в стандартную схему — кастом решает.

3) Требуется максимальная гибкость по интеграциям и данным

Бизнесу может быть важно:

• как именно передаются статусы заказов
• какие данные собираются
• как строится аналитика
• как работает связка сайт + приложение + CRM + касса

В некоторых проектах это критично.

И тогда кастомная архитектура позволяет собрать именно ту систему, которая подходит бренду.

4) Есть стратегия “долгой жизни” цифрового продукта

Кастом — это уже не “запустить доставку”. Это история, когда цифровой продукт становится частью бизнеса.

Например:

• приложение становится главным каналом коммуникации
• лояльность — финансовым контуром
• CRM — ядром управления гостями
• а доставка — одним из сценариев

В таком подходе важно строить не “временное решение”, а платформу под рост.

Простой критерий выбора

Можно сформулировать очень по-честному:

✅ Если нужно быстро запуститься и работать стабильно — берите готовую платформу.

✅ Если продукт — часть вашего бренда и стратегии — делайте кастом.

И ещё проще:

• Готовое решение — когда важнее скорость и стоимость владения
• Кастом — когда важнее уникальность и точность под процессы

Важное: это не «или-или»

На практике сильнейшая стратегия часто гибридная:

• начать с готовой платформы (быстро запустить и заработать)
• параллельно собрать требования и UX
• затем — перейти в кастом, когда бизнес “созрел”

И это нормально.

Мы в РЕСТОЦРМ / RESTOCRM именно так часто и работаем:

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