Разработка мобильного приложения для ресторана
Ресторанное приложение — это не просто цифровое меню. Оно должно синхронизироваться с кухней, кассой и залом. Если стоп-лист на кухне обновился, а приложение показывает блюдо доступным — заказ принят, кухня его отменила, официант объясняет ситуацию. Технически это решается, но требует правильной архитектуры с самого начала.
Меню: real-time или cached
Два подхода. Статическое меню — JSON, загружается при старте приложения, кэшируется на 24 часа. Просто, быстро, работает оффлайн. Минус: стоп-лист обновляется с задержкой, пользователь может заказать недоступное блюдо.
Динамическое меню — загрузка актуального состояния перед каждым взаимодействием с корзиной. Медленнее, требует интернета. Компромисс: кэшируем меню на 5–15 минут, при открытии корзины — принудительный refresh с проверкой доступности каждой позиции.
Стоп-лист — отдельный endpoint GET /menu/stop-list, обновляется через WebSocket или polling. Позиции из стоп-листа показываем с меткой «Временно недоступно» — не скрываем, это лучше для UX.
Бронирование столиков
Схема зала — SVG или Canvas с кликабельными столиками. Каждый столик: вместимость, статус (свободен/занят/забронирован). Статус в реальном времени через WebSocket или polling каждые 30–60 секунд.
Форма бронирования: дата, время, количество гостей, имя, телефон, комментарий. После подтверждения — SMS и push-уведомление с деталями. За час до бронирования — reminder push.
Отмена бронирования — через приложение, не звонком. Освобождённый слот автоматически становится доступным для других пользователей.
Предзаказ и доставка
Режим «взять с собой» — пользователь заказывает заранее, указывает время готовности. Статусы заказа: принят → готовится → готов. Push на каждый статус.
Доставка — отдельная логика: зоны доставки (polygon на карте), минимальная сумма, расчёт стоимости доставки (фиксированная или по зонам). Интеграция с Яндекс.Картами / Google Maps для ввода адреса с автодополнением (Places API).
Программа лояльности
Накопительные баллы — самый популярный механизм. Схема начисления: X баллов за Y рублей. Списание: баллами оплачивается часть заказа (не более N%). Баланс баллов — на главном экране и в профиле.
QR-код для накопления баллов при оффлайн-визите: в приложении генерируется уникальный QR (JWT-подписанный, с timestamp для защиты от повторного использования), кассир сканирует — баллы зачисляются.
Push-кампании: «Ваши баллы сгорают через 30 дней», «Вы не были у нас 2 недели — вот промокод». Это не спам — это retention-механика. FCM Topic-подписки для сегментации.
Интеграция с кассой
POS-системы: iiko, r_keeper, Poster. У каждой есть API для передачи заказов. iiko API — REST, передаём заказ с позициями и модификаторами, получаем orderId в iiko, по которому отслеживаем статус. Это убирает ручной перенос заказов — повар видит их прямо на кухонном экране.
Если POS-интеграция не входит в первую версию — синхронизация через tablet-приложение для персонала (отдельный target/app, уведомления о новых заказах).
Стек и архитектура
Flutter — хороший выбор для ресторанного приложения: одна кодовая база, быстрый старт. BLoC для стейта заказа и корзины (предсказуемые состояния, легко тестировать). dio + retrofit для API. hive для кэша меню. flutter_local_notifications + FCM для уведомлений.
Нативная разработка — если нужна глубокая интеграция с hardware (NFC для списания баллов, Bluetooth-принтер для чеков самовывоза).
Процесс
Дизайн меню и флоуса заказа → разработка каталога и корзины → бронирование → программа лояльности → платёжная интеграция → POS-интеграция (если в scope) → тестирование всех флоусов → публикация.
Ориентиры по срокам
MVP (меню, корзина, онлайн-оплата, push-уведомления): 3–5 недель. Полноценное приложение с бронированием, программой лояльности и POS-интеграцией: 2–3 месяца. Стоимость рассчитывается индивидуально.