Mobile app for a restaurant: where orders get lost
A guest opens a restaurant mobile app, finds an item in the in-app digital menu — but it has been unavailable in the kitchen since opening: the stop list was updated at the POS but not in the app.
A conversation with the waiter no longer saves the situation: some guests close the app and go to neighbors, some still order, and the item is removed manually at handoff.
The root of the problem is that the menu lives in two independent places. The POS system holds current stock and the stop list; the app has its own copy, updated manually or on a schedule once a day.
Between updates, orders are accepted using an outdated stop list, and every such order comes back to the guest as a rejection after payment.
Abandoned carts add their share. A guest assembles an order, but at checkout is met by mandatory registration, re-entering the address, or a changed price — and the cart empties.
When the connection drops, the state is lost completely: the app does not remember what has already been selected, and the order starts from scratch.
What should be measured here is not installs or opens, but the share of carts that reach payment and the number of rejections due to missing items.
Next, we break down how this is closed: a single menu source instead of two copies, event-driven synchronization with the POS, and a cart that survives a restart and network loss.
What a mobile app gives the venue owner
Electronic menu and stop list live in one panel: the administrator changes a price, composition, or removes an item — guests see it within a minute, without reprinting and distributing edits across the floor.
Stop-list updates stop being a verbal agreement between shifts and become a system state, so the waiter does not spend the evening explaining "we're out of that."
Guest self-service adds a second order-taking channel: a guest opens the menu from their phone and assembles the order themselves.
During peak hours, this offloads waiters and the floor — some tables are closed without staff involvement, and seating and table turnover grow without expanding staff or space.
Order history and saved preferences reduce the path to a repeat order to two taps. The venue gets a database that shows who returns and what they order — repeat orders no longer depend on whether the guest remembers a specific employee.
Cancellations decrease at the order-taking stage: composition, price, and add-ons are confirmed before sending to the kitchen, and the "said vs. heard" mismatch disappears along with verbal retelling. The guest sees the order status themselves and does not bother staff unnecessarily.
All these effects are measurable: menu update time, share of orders placed by the guest themselves, share of repeat visits, share of cancellations — calculated from events in the app, not from gut feeling. Next, the venue's development plan is built on these numbers, not on an argument about tastes.
Own app, web menu, and aggregator: what to choose
A guest sits at a table, scans a code, and wants to see dishes within seconds — this scenario breaks most "universal" solutions. The web menu via a link responds fastest: it opens in a browser, requires no installation, and is edited from the floor in minutes.
Then limitations begin: no push notifications, reduced access to device functions, and the guest returns only if they saved the link.
A delivery aggregator brings a flow of orders immediately, but your branded menu lives inside someone else's interface. The guest remains a platform client: impressions, commission, and reviews are regulated by the platform, while order history and contacts remain with it.
The venue's own app removes these limitations — notifications, loyalty program, repeat order in one tap — but requires installation and regular updates.
| Option | When it fits | Limitations |
|---|---|---|
| Web menu via link | You need a launch in a matter of days, QR on the table, menu and pre-order without installation | No notifications, reduced access to device functions, guest returns only via a saved link |
| Delivery aggregator | You need a flow of orders immediately, and you delegate logistics to the platform | The brand lives in someone else's interface, terms are set by the platform, guest data is unavailable to you |
| Venue's own app | Loyalty, repeat visits, order history, menu management from the floor | Installation is required, plus your own acquisition channel and ongoing support |
In practice, the three channels do not compete: the web menu covers quick entry, the app covers repeat visits and loyalty, and the aggregator brings in new guests.
From menu schema to publishing: stages of work
The order of stages is not for reporting: the menu changes every season, while the app lives for years, so a mistake in the data schema at the start is the most expensive. Below are the app development stages from menu analysis to handover to the restaurant.
- Menu and guest scenario analysis. We collect categories, stop lists, seasonal items, and the guest path to order submission: how many screens, where they leave most often, what the waiter lacks.
- Menu and modifier schema. We design the data structure — dish, group, option, surcharge, availability by time and floor. After that, the menu is filled in by the manager, without a developer and without the risk of breaking the screen.
- Integration with the POS and back-office system. Exchange is two-way: the menu and stop lists come from the back-office system, orders go back. We separately define behavior when the POS is unavailable: the order is queued and is not lost.
- App assembly. Menu, cart, payment, loyalty — one codebase for iOS and Android, so price and stop list do not diverge between platforms. Images are cached, and the list opens even on a weak connection.
- Pilot launch on the floor. Two or three shifts in normal mode: we look at where the waiter duplicates the order by hand and where the guest abandons the cart. We make edits before publishing, not after.
- Publishing in app stores and handover. Listings, moderation, phased release to part of the audience, rollback version. Then — access, menu update procedures, and an on-call engineer.
Handover package: access, schemas, procedures
The handover package is not a folder with source code, but a set of artifacts your team can work with independently: without us, but with full understanding of what is where and who is responsible for what.
Below is what we record in the acceptance act, and for each item we check together that access is granted and actually works.
- Employee access and roles. Menu management, analytics, and notification panels are transferred to your accounts with owner rights. Inside, we configure roles: the manager changes prices and section composition, the floor manager edits the stop list and dish availability, the waiter only views and confirms the order.
- System connection schema. One page: app, menu panel, POS system, payment service, notification service — who exchanges data with whom and what happens to the order if one link fails.
- Menu update procedure. Who makes changes, at what point they appear to guests, how the cache on devices is updated, what to do with discontinued dishes so they do not remain in old builds.
- Instructions for floor staff. Opening and closing shifts, showing the menu and paying at the table, actions during connection loss, typical guest questions — on one page, to help a new employee.
- App stores. Developer accounts and listings are transferred to you, signing keys and the update release procedure are documented, and any team you choose can release new versions.
- Support and update procedure. Request channels, priorities, response times for payment failure or storefront outage, and the procedure for approving urgent edits during the season.
- Data schema and change history. Structure of dishes, categories, and modifiers with an export example — so reporting and integrations can be expanded without taking the app apart again.
The result of handover — you manage the menu, prices, and roles yourself, and contact us for development, not for every item edit. Describe the task — we will return with a work plan and an estimate of the composition of such a package for your restaurant.
Case: a pizzeria chain removed manual menu updates
Before: edits in four places and a late stop list
A pizzeria chain Tri Pechi had its menu in four independent places: website, app, delivery aggregators, and the POS in the dining room. A price or composition edit was made manually in each — from 40 minutes of administrator work, and during the evening peak it reached two hours.
Discrepancies surfaced not immediately: a guest saw one price on the website, another in the aggregator, and this settled as refunds.
The stop list was more expensive. When the kitchen ran out of topping, the item was removed in the app, but on other channels it remained available for about another hour.
The order managed to go to the kitchen, the operator called the guest with a cancellation or substitution — this is where the main share of canceled orders accumulated, around eight percent during peak shifts.
What was changed and what resulted
The menu was consolidated to one source: an edit in the admin panel spreads across the website, app, and aggregators within a minute; the stop list is set in the same place and closes the item across all channels simultaneously.
A local cache keeps the menu on the device, so in a dining room with a weak connection the guest sees the current composition, not yesterday's.
Menu updates now take 2–3 minutes instead of an hour, and the stop list reaches all points of sale without manual actions.
The share of canceled orders decreased by about three times — to 2–3%, and administrators stopped duplicating one edit in four windows and returned to work on the floor.
What to do if the menu and prices change several times a day?
A menu with several edits a day breaks an app if it stores a copy of the item list locally.
The waiter already knows the soup is out, while the guest in the dining room still sees it as available and waits for the order — in debriefs, this is the most common cause of negative reviews.
In such a scenario, every edit turns into releasing a new build, store review, and a day of waiting.
We do not duplicate the menu inside the app: it works from a single data source — the restaurant's back-office system, whether iiko or another POS. Items, prices, composition, and availability come from there, while the app keeps only a local copy for fast startup. A change made by the technologist becomes visible to guests without developer involvement.
Edits do not go to the floor instantly — delayed publication of changes is used. A new price or composition is prepared as a draft and a start time is assigned: from opening, for business lunch, after the kitchen closes.
If something goes wrong, the previous state is restored with one command, not by rolling back the entire app.
Stop-list checking deserves separate mention: the assortment is reconciled with actual stock, and the item is automatically moved to "out of stock" — the guest sees it as unavailable instead of receiving a rejection after placing the order.
Updating without restart means the current set is pulled at startup, on return from background, and by a service signal: the waiter does not need to ask the guest to close and reopen the app.
As a result, frequent menu edits stop being project work and become the technologist's routine in the back-office system, while the floor and the app show the same thing. Below is how we deploy such an integration and what we check before launch.
Offline mode, staff roles, and updates: technical details
Before launching the app, the same questions come up: what happens during peak hours if Wi-Fi disappears, what each staff member sees, how payment works. Below are five nodes that we most often review with the client before development starts.
What happens to an order if the network disappears?
The app writes the order to a local queue and sends it when the connection returns. A unique operation key prevents creating a duplicate on resend, while the menu and stop list remain available from the local cache.
How is staff access separated?
Access is built on roles: waiter, kitchen, bar, manager, owner. Rights are set at the operation level — send an order, cancel an item, close a shift — and every action goes into the log.
How is payment accepted inside the app?
The payment is processed by the payment provider; the app receives only the result and does not store card data. Payment is possible at the POS, via a terminal, or directly in the app, and the receipt goes to fiscalization.
What can be changed after launch?
Menu, prices, stop lists, and promotions are edited on the server without rebuilding the app. Logic is updated through app stores, so the exchange interface is versioned — an outdated version continues to work for the guest.
What order analytics is available?
We collect order events: composition, time from opening the menu to submission, cancellations, repeat visits. Reports are exported to the accounting system the restaurant already has, rather than remaining inside the app.
Let's discuss the task and return with a work plan
To return with a work plan, we need a minimum of inputs: how many locations and dining rooms, which POS and back-office system is already installed, how the menu is currently updated and who maintains stop lists, whether there is delivery, and on which devices the waiters work. This is enough to estimate the scope and avoid sending you through ten clarifying emails.
For the estimate, we attach not a list of technologies, but documents that show how the app will live in the restaurant:
- work plan for the app: stages, duration of each, and what is considered complete at the output;
- scope of work and handover — what exactly goes to you: code, build configurations, access, instructions for floor administrators;
- schema of connections with the POS and kitchen: what data goes in which direction, where the menu is stored, how the app behaves during a connection loss;
- floor testing procedure: scenarios on a real dining room during peak hours — stop list, table change, order printing, guest with two devices;
- launch procedure: pilot launch at one location, phased activation of the rest, transition criteria, and rollback conditions;
- support procedure: where a request goes, how quickly we respond, who on the restaurant side makes the decision.
Describe the task in a convenient form — correspondence, a call with the restaurant's technologist, or access to the current menu. We will return with an estimate, a work plan, and the handover composition.