We've encountered a common pain point: a guest scans a QR, browses the menu, adds items, taps "Order" — and nothing happens. Wi-Fi drops, the order is lost. Our experience in building restaurant mobile app shows that reliable real-time ordering and proper error handling are key to success. This custom mobile app focuses on table ordering and seamless iiko integration.
With over 10 projects in HoReCa, we've built an architecture that saves up to 20% on payroll (approx. $2,000/month for a mid-size restaurant) and increases average check by 15–30% ($3–$5 per guest) by reducing service time and upsell prompts. Tech stack: Flutter 3.x for client, Laravel 10 with Broadcasting for server, PostgreSQL 15 and Redis 7 for storage and caching. We use WebSocket for instant data transfer (see Wikipedia on WebSocket).
Seamless Order Synchronization via WebSocket
An order from the app must instantly appear on the kitchen display system (KDS). We use a WebSocket connection: the app sends the order → Laravel Broadcasting publishes an event to the kitchen channel → KDS receives the event and displays the new item. If multiple devices are at one table (tablets and phones for a large party), orders are aggregated into a single kitchen ticket. The table session identifier is the aggregation key. WebSocket ensures latency under 100 ms, which is 5 times faster than HTTP polling.
| Component | Technology | Version |
|---|---|---|
| Client | Flutter (or PWA for QR mode) | 3.x |
| Server | Laravel + Broadcasting | 10 |
| Database | PostgreSQL + Redis | 15, 7 |
| Push | FCM | latest |
| POS | iiko / r_keeper / Poster | REST API |
What Happens When Connection Is Lost?
A critical moment: the guest taps "Order", no response (Wi-Fi drops). The app must show a "Sending" status with retries using exponential backoff, not silently lose the order or display "Error, try again". We implement retry with increasing intervals (1s, 2s, 4s…) up to 30 seconds — enough for connection recovery. If two guests simultaneously add the same dish, the server uses optimistic locking — the last operation wins and the client receives the updated state.
Cart Synchronization Across Table Devices
If multiple people at a table order from different devices, the cart is a shared server state, not a local list. When any participant adds an item, all table devices receive an update via WebSocket. The architecture changes: instead of local HydratedBloc — server-side cart with WebSocket subscription, optimistic update on the client, and confirmation from the server. Data is encrypted; the channel is protected by a certificate.
Table Identification
Each table's QR code contains a URL with table_id or an encrypted session token. Scanning opens either the web version in a browser (no installation) or a Universal Link in the installed app. For tablet mode — kiosk mode (Android Task Locking / iOS Guided Access), always open on the correct table.
POS Integration
The completed order goes to the POS system via a Laravel adapter: transform into the POS format → POST to the API (usually REST). The reverse flow — "dish ready" status from KDS → push to the guest's device via FCM.
Our Work Process
- Analysis — study processes, number of tables, device types (tablets/personal phones), POS system.
- Design — real-time architecture (WebSocket vs SSE), stack selection, data schema.
- Development — implement client (Flutter/PWA) and server (Laravel).
- Testing — load testing (500+ concurrent orders), connection break scenarios.
- Deployment — App Store / Google Play, push setup, KDS, POS.
Client Solution Comparison
| Feature | PWA | Native (Flutter) |
|---|---|---|
| Installation | Not required | Required |
| Push notifications | Limited (Android only) | Full support |
| Device API access | Limited | Full |
| Development speed | Faster | Slower |
| Recommended for | Quick start | Complex scenarios |
What's Included
- Source code of the app (client + server)
- CI/CD setup, app store deployment
- POS integration (up to 2 adapters)
- Architecture and API documentation
- Staff training (2–3 hours)
- 6-month warranty on critical bugs
Timelines and Cost
Basic version (QR menu, cart, send to kitchen) — from 12 weeks. Full package with multi-device cart and iiko integration — up to 18 weeks. Cost is calculated individually — reach out to us, and we'll evaluate your project in 2 days. Contact us for a detailed discussion of your project — we'll prepare a proposal tailored to your needs.
Why Choose Us?
Over 5 years in the market, 10+ HoReCa solutions delivered. We guarantee compliance with App Store Review Guidelines (Section 4.2, 5.1) and Google Play requirements. We provide code signing certificates, configure push notifications (APNs / FCM). Our experience ensures reliable operation under load.