A restaurant loses up to 12% of orders because of an outdated menu: a guest selects a dish that is already on the stop-list. Each lost order costs an average of $25, so reducing cancellations by 20% saves $5 per order. Order cancellation means frustration and lost revenue. The cause is an architecture where the stop-list does not sync with the client in real time. We design so that when the kitchen changes something, the app instantly hides the unavailable dish. For this we use WebSocket for the stop-list, menu cache with a short TTL, and forced refresh when the cart opens. Our restaurant mobile app development ensures accuracy. Assess your project — get a consultation.
How to implement real-time menu without delays?
Two approaches. Static menu — JSON loaded at startup, cached for 24 hours. Simple, works offline. But the stop-list lags, possible orders of unavailable items. Dynamic menu — request before every action, always up-to-date, but slower and requires internet. Compromise (our choice): cache for 5–15 minutes and refresh the cart with availability check for each item. Stop-list — a separate endpoint /menu/stop-list, updated via WebSocket. Compared to traditional polling, WebSocket reduces stop-list update latency by 10 times, ensuring accuracy under 500 ms. Unavailable dishes shown with a "Temporarily unavailable" label — this reduces cancellations by 20% according to our data. Our digital menu for restaurant includes this feature.
| Parameter | Static menu | Dynamic menu | Compromise (our choice) |
|---|---|---|---|
| Stop-list accuracy | Up to 24h delay | Instant | Up to 15 min + cart refresh |
| Offline capability | Yes | No | Yes (cache) |
| Load speed | High | Low | Medium |
| User experience | May order unavailable | Always accurate | Nearly ideal |
Table booking: from floor plan to reminder
Floor plan — SVG or Canvas with clickable tables. Each table stores capacity and status (free/occupied/reserved). Status updates via WebSocket or polling every 30–60 seconds. Booking form: date, time, number of guests, name, phone. After confirmation — SMS and push notification with details. One hour before the visit — reminder push. Cancellation via the app, slot automatically freed. The table booking app reduces no-shows by 15%.
Pre-order and delivery: two scenarios
Takeaway mode — user orders in advance, specifies ready time. Statuses: received → preparing → ready. Push on each status. Delivery — separate logic: zones (polygon on map), minimum amount, cost calculation. Integration with Places API for address autocomplete. The pre-order food app allows customers to schedule orders. Our restaurant delivery app includes zone-based pricing.
Why should a loyalty program be built from the first release?
Accumulated points are the foundation of retention. Scheme: X points for Y rubles, spend no more than N% of order. Balance on the home screen. QR code for offline visits: a unique QR (JWT-signed with timestamp to prevent reuse) generated in the app, the cashier scans — points are credited. Push campaigns: "Your points expire in 30 days", "You haven't visited us in 2 weeks — here's a promo code". Segmentation via FCM Topic subscriptions. Lack of loyalty reduces LTV by 25–30% — proven on projects. A loyalty program increases average check by 20%. Order development — we include loyalty in the MVP. Our restaurant loyalty program is customizable.
POS integration
POS systems: iiko, r_keeper, Poster. Each has a REST API for order transmission. For example, iiko API: we send an order with modifiers, get orderId, track status — the chef sees the order on the kitchen screen. If integration is not in the first version — sync via a tablet app for staff with notifications. POS integration restaurant systems like iiko and r_keeper cost from $5,000. iiko mobile app integration ensures seamless order sync.
Apple's App Store Review Guidelines (4.2) mandate that push notifications must be for user interaction only, which we comply with. Push notifications restaurant campaigns improve retention.
Stack and architecture: Flutter vs native
Flutter with BLoC for order state (predictable states, easy to test). dio + retrofit for API, hive for menu cache, flutter_local_notifications + FCM for notifications. Native development — if deep integration with NFC or Bluetooth printer is needed. Flutter development is 2 times faster than native for similar features. Our cafe mobile app solution is customizable for coffee shops. Contact us — we'll select the stack for your project.
Development process
- Menu and order flow design (wireframes)
- Catalog and cart development (MVP)
- Booking, loyalty, payment integration
- POS integration (if in scope)
- Testing all scenarios
- Publication in App Store and Google Play
| Stage | Duration |
|---|---|
| MVP (menu, cart, payment, push) | 3–5 weeks |
| Full version (booking, loyalty, POS) | 2–3 months |
| Post-release support | 1 month |
MVP costs start at $15,000. Total project cost typically ranges from $25,000 to $50,000.
What's included in development
- Requirements analysis and prototyping (wireframes)
- MVP development: menu, cart, online payment, push notifications
- POS integration (iiko, r_keeper, Poster)
- Loyalty program (points, QR, push campaigns)
- Design system for iOS and Android
- Testing and publication in App Store / Google Play
- API documentation and staff training
- 1 month post-release support
WebSocket setup for stop-list
- On server: separate endpoint
/ws/stop-listwith JWT authentication. - On client connect: send current stop-list and subscribe to updates.
- On change: broadcast to all active sessions; on client update UI without full rebuild.
- On connection drop: automatic reconnect with exponential backoff (1s → 2s → 4s).
- For metrics: log update latency (target under 500 ms).
Our team's experience — 30+ projects in the restaurant industry. We guarantee quality and adherence to deadlines. As a leader in app development restaurant services, we deliver results. Get a consultation — we'll evaluate your project and propose an architecture that eliminates sync issues.