Разработка мобильного приложения для ресторана (бронирование столов)
Бронирование стола в ресторане — это задача с временными слотами, вместимостью, депозитами и правилами отмены. На первый взгляд проще, чем доставка. На деле — несколько нетривиальных технических узлов, которые определяют, работает ли система или раздражает.
Модель данных для резервирования
Главная ошибка при проектировании — хранить бронирования просто как строки в таблице с datetime. Это работает до первого «стол на 4 занят частично» или «гость хочет столик у окна или у бара».
Правильная модель: Table (номер стола, вместимость, зона, особенности) → Reservation (стол, datetime start, datetime end, guests count, status, deposit status) → Guest (профиль, история визитов, предпочтения).
Проверка доступности: при выборе даты и числа гостей запрос к бэкенду возвращает доступные временные слоты. Сервер проверяет: нет пересечений по времени (с учётом среднего времени оборота стола — настраиваемый параметр, например 90 минут), есть столы нужной вместимости. Это серверная логика, не клиентская — чтобы исключить race condition при одновременных бронях.
Депозит и политика отмены
Ресторан хочет застраховаться от no-show. Депозит при бронировании через ЮКасса — холдирование суммы на карте (метод hold), списание при подтверждении визита или возврат при отмене в установленные сроки. Это не авторизация и не полная оплата — именно холдирование, которое ЮКасса поддерживает.
Политика отмены: бесплатно за 24 часа, 50% депозита за 4 часа, 100% при no-show. Логика на бэкенде — Laravel scheduled jobs проверяют бронирования за час до наступления дедлайнов.
Уведомления
Push через FCM: подтверждение брони сразу, напоминание за 24 часа и за 2 часа. Если ресторан принимает бронирование вручную (не автоматически) — пуш «Ваш столик подтверждён» после одобрения менеджером.
SMS через СМСЦентр как резервный канал — не все пользователи разрешают push.
Административная панель
Менеджер ресторана видит план зала на сегодня с визуализацией занятых/свободных столов, может изменить бронирование, добавить заметки («аллергия на орехи», «день рождения»), отметить no-show. Веб-интерфейс на React — удобнее для десктопа в зале.
Стек
Flutter 3.x (клиентское приложение), Laravel 10 + PostgreSQL, FCM, ЮКасса с hold-платежами, React для панели ресторана.
Приложение с бронированием, депозитами, уведомлениями и административной панелью — от 12 до 16 недель. Стоимость рассчитывается индивидуально после анализа требований.