Розробка мобільного додатку для ресторану
Ресторанне приложение — це не просто цифрове меню. Воно повинно синхронізуватися з кухнею, касою та залом. Якщо стоп-лист на кухні оновився, а додаток показує блюдо доступним — замовлення прийняте, кухня його скасувала, офіціант пояснює ситуацію. Технічно розв'язується, але вимагає правильної архітектури з самого початку.
Меню: real-time або cached
Два підходи. Статичне меню — JSON, завантажується при старті додатку, кешується на 24 години. Просто, швидко, працює offline. Мінус: стоп-лист оновлюється з затримкою, користувач може замовити недоступне блюдо.
Динамічне меню — завантаження актуального стану перед кожною взаємодією з корзиною. Повільніше, потребує інтернету. Компроміс: кешуємо меню на 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-код для накопління балів при offline-відвідуванні: в додатку генерується унікальний 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 (меню, корзина, online-оплата, push-сповіщення): 3–5 днів. Полноценное приложение з бронюванням, програмою лояльності та POS-інтеграцією: 2–3 місяці. Вартість розраховується індивідуально.