Ресторан теряет до 12% заказов из-за неактуального меню: гость выбирает блюдо, а оно уже в стоп-листе. Отмена заказа — раздражение и потерянная выручка. Причина — архитектура, где стоп-лист не синхронизируется с клиентом в реальном времени. Мы проектируем так, чтобы при изменении на кухне приложение мгновенно скрывало недоступное блюдо. Для этого используем WebSocket для стоп-листа, кэш меню с коротким TTL и принудительный refresh при открытии корзины. Оцените свой проект — получите консультацию.
Как реализовать real-time меню без задержек?
Два подхода. Статическое меню — JSON загружается при старте, кэшируется на 24 часа. Просто, работает офлайн. Но стоп-лист отстаёт, возможны заказы недоступных позиций. Динамическое меню — запрос перед каждым действием, всегда актуально, но медленнее и требует интернета. Компромисс (наш выбор): кэш на 5–15 минут и refresh корзины с проверкой доступности каждой позиции. Стоп-лист — отдельный endpoint /menu/stop-list, обновляется через WebSocket. Недоступные блюда показываем с меткой «Временно недоступно» — это снижает отказы на 20% по нашим данным.
| Параметр | Статическое меню | Динамическое меню | Компромисс (наш выбор) |
|---|---|---|---|
| Актуальность стоп-листа | Задержка до 24 ч | Мгновенно | До 15 мин + refresh корзины |
| Работа офлайн | Да | Нет | Да (кэш) |
| Скорость загрузки | Высокая | Низкая | Средняя |
| Пользовательский опыт | Может заказать недоступное | Всегда актуально | Почти идеален |
Бронирование столиков: от схемы до напоминания
Схема зала — SVG или Canvas с кликабельными столиками. Каждый столик хранит вместимость и статус (свободен/занят/забронирован). Статус обновляется через WebSocket или polling каждые 30–60 секунд. Форма бронирования: дата, время, количество гостей, имя, телефон. После подтверждения — SMS и push-уведомление с деталями. За час до визита — reminder push. Отмена бронирования — через приложение, слот автоматически освобождается.
Предзаказ и доставка: два сценария
Режим «взять с собой» — пользователь заказывает заранее, указывает время готовности. Статусы: принят → готовится → готов. Push на каждый статус. Доставка — отдельная логика: зоны (полигон на карте), минимальная сумма, расчёт стоимости. Интеграция с Places API для автодополнения адреса.
Почему программа лояльности должна быть встроена с первого релиза?
Накопительные баллы — основа retention. Схема: X баллов за Y рублей, списание не более N% заказа. Баланс — на главном экране. QR-код для офлайн-визитов: в приложении генерируется уникальный QR (JWT-подписанный с timestamp для защиты от повторного использования), кассир сканирует — баллы начисляются. Push-кампании: «Ваши баллы сгорают через 30 дней», «Вы не были у нас 2 недели — вот промокод». Сегментация через FCM Topic-подписки. Отсутствие лояльности снижает LTV на 25–30% — проверено на проектах. Закажите разработку — мы включим лояльность в MVP.
Интеграция с кассой
POS-системы: iiko, r_keeper, Poster. Каждая имеет REST API для передачи заказов. Например, iiko API: отправляем заказ с модификаторами, получаем orderId, по нему отслеживаем статус — повар видит заказ на кухонном экране. Если интеграции нет в первой версии — синхронизация через tablet-приложение для персонала с уведомлениями.
App Store Review Guidelines 4.2 — приложение должно использовать push-уведомления только для прямого взаимодействия с пользователем, не для спама. Мы соблюдаем это.
Стек и архитектура: Flutter vs нативный
Flutter с BLoC для стейта заказа (предсказуемые состояния, легко тестировать). dio + retrofit для API, hive для кэша меню, flutter_local_notifications + FCM для уведомлений. Нативная разработка — если нужна глубокая интеграция с NFC или Bluetooth-принтером. Свяжитесь с нами — подберём стек под ваш проект.
Процесс разработки
- Дизайн меню и флоуса заказа (wireframes)
- Разработка каталога и корзины (MVP)
- Бронирование, лояльность, платёжная интеграция
- POS-интеграция (если в scope)
- Тестирование всех сценариев
- Публикация в App Store и Google Play
| Этап | Длительность |
|---|---|
| MVP (меню, корзина, оплата, push) | 3–5 недель |
| Полная версия (бронирование, лояльность, POS) | 2–3 месяца |
| Поддержка после релиза | 1 месяц |
Что входит в разработку
- Анализ требований и прототипирование (wireframes)
- Разработка MVP: меню, корзина, онлайн-оплата, push-уведомления
- Интеграция с кассой и POS (iiko, r_keeper, Poster)
- Программа лояльности (баллы, QR, push-кампании)
- Дизайн-система под iOS и Android
- Тестирование и публикация в App Store / Google Play
- Документация API и обучение персонала
- Поддержка 1 месяц после релиза
Настройка WebSocket для стоп-листа
- На сервере: отдельный endpoint
/ws/stop-listс аутентификацией по JWT. - При подключении клиента отправляем текущий стоп-лист и подписываем на обновления.
- При изменении — broadcast всем активным сессиям; на клиенте обновляем UI без полного ребилда.
- При падении соединения — автоматический reconnect с экспоненциальной задержкой (1с → 2с → 4с).
- Для метрик: логируем задержку обновления (цель — менее 500 мс).
Опыт нашей команды — 30+ проектов в ресторанной сфере. Мы гарантируем качество и соблюдение сроков. Получите консультацию — оценим проект и предложим архитектуру, которая исключит проблемы с синхронизацией.