Restaurant Mobile App Development
A restaurant app isn't just a digital menu. It must sync with kitchen, register, and floor. If the kitchen's stop-list updates but the app shows a dish available — order taken, kitchen cancels it, waiters explain. Technically solvable, but requires correct architecture from the start.
Menu: Real-time or Cached
Two approaches. Static menu — JSON loaded at startup, cached 24 hours. Simple, fast, works offline. Downside: stop-list updates with delay, user can order unavailable dish.
Dynamic menu — load current state before each interaction with cart. Slower, needs internet. Compromise: cache menu 5–15 minutes, force refresh when opening cart, check availability for each item.
Stop-list — separate endpoint GET /menu/stop-list, updates via WebSocket or polling. Show stop-listed items with "Temporarily unavailable" label — don't hide, better for UX.
Table Reservations
Floor plan — SVG or Canvas with clickable tables. Each table: capacity, status (free/occupied/reserved). Status real-time via WebSocket or polling every 30–60 seconds.
Booking form: date, time, guests, name, phone, comment. After confirmation — SMS and push with details. Reminder push 1 hour before.
Cancellation via app, not call. Released slot immediately available for others.
Advance Orders and Delivery
"Takeaway" mode — user orders in advance, specifies ready time. Statuses: accepted → cooking → ready. Push on each status.
Delivery — separate logic: delivery zones (polygon on map), minimum sum, delivery cost calculation (fixed or by zones). Integration with Yandex.Maps / Google Maps for address input with autocomplete (Places API).
Loyalty Program
Accumulation points — most popular. Scheme: X points per Y rubles. Spending: points pay part of order (not over N%). Points balance on home screen and profile.
QR for offline accumulation: app generates unique QR (JWT-signed, timestamped to prevent reuse), cashier scans → points credited.
Push campaigns: "Your points expire in 30 days", "Haven't seen you in 2 weeks — here's a promo code". Not spam — retention mechanics. FCM Topic subscriptions for segmentation.
POS Integration
POS systems: iiko, r_keeper, Poster. Each has API for order transmission. iiko API is REST — send order with items and modifiers, get orderId in iiko, track status there. Eliminates manual order entry — chef sees them on kitchen screen.
If POS integration not in v1 — sync via tablet app for staff (separate target/app, notifications about new orders).
Stack and Architecture
Flutter — good choice for restaurant app: one codebase, fast start. BLoC for order and cart state (predictable states, easy to test). dio + retrofit for API. hive for menu cache. flutter_local_notifications + FCM for notifications.
Native dev — if you need deep hardware integration (NFC for point deduction, Bluetooth printer for takeaway receipts).
Process
Design menu and order flow → develop catalog and cart → reservations → loyalty program → payment integration → POS integration (if in scope) → test all flows → launch.
Timeline
MVP (menu, cart, online payment, push): 3–5 weeks. Full app with reservations, loyalty program, POS integration: 2–3 months. Pricing calculated individually.







