An online order is a contract with a kitchen mid service.
An online ordering app for restaurants is not a shop with food in it. A shop takes money for a thing that already exists. An order takes money for a promise a kitchen now has to keep, in the next twenty minutes, while six other promises are already on the pass. Everything hard about this category follows from that, and almost none of it is solved by a nicer menu screen. The wider decisions sit on the restaurant app builder page.
This page covers what an order has to carry beyond a cart, why the kitchen display is the real product and the printer is a liability, what happens when an item runs out at half past seven, how the money actually moves, and the calorie rule that arrives with your twentieth location.
See what the queue does to a promised timeThe short version
A cart holds items, an order holds instructions.
The gap between an ecommerce cart and a restaurant order is instructions. No basil, gluten free base, ring the bell twice, wanted at seven rather than now. A cart that stores a product and a quantity throws all of that away, and the kitchen finds out at the pass.
The second gap is time. An order is good for about twenty minutes and then it is rubbish, so the app has to know what the kitchen can absorb before it accepts anything. Build the ticket and the queue first. The menu screen is the easy half.
What an order has to carry that a cart does not
Take one line off a real ticket: a large margherita, no basil, gluten free base, chilli oil on the side, for someone who cannot have nuts. That is one product and four instructions, and three of them change what the kitchen does rather than what the customer pays.
Modifiers are therefore not a pricing feature. They are the instruction set, and they need structure: which are exclusive, which stack, which change the cook time, which are simply unavailable on that base. Kept as free text in a notes field, they become a game of telephone that the pass loses.
Allergens are a field, not a note
An allergen declaration belongs in its own structured field, apart from the free text, because it changes who makes the dish and what gets checked before it leaves. Arriving as a sentence in a comment box, it is read by whoever happens to look, which is not a control. Keep the free text as well, since people explain themselves in ways no checkbox covers.
Collection and delivery are different orders
They differ by more than a fee. A collection order has a person who turns up at a time. A delivery order has an address, an access note, a driver, and a window that starts when the food leaves rather than when it is cooked. Fire times differ, packaging differs, and the failure modes are unrelated: one goes cold on a shelf, the other goes cold in a bag on a car seat.
Prep time is part of the order
A flat twenty minute quote on every order is the most common defect in this category. The honest number depends on what is already in the queue and what this ticket needs, and it moves through the night. Quoting a number you cannot justify is not friendliness, it is choosing which customer gets angry.
Try it
What the queue does to a promised time
Most ordering apps quote a flat 20 minutes. This is the same sum the pass is doing. Every number here is yours to set, none of them is a benchmark.
29 minutes, honestly
18 of those minutes are the queue, before anyone touches this order. A flat 20 minute quote is 9 minutes short, and the customer finds out by standing at the counter. The number the app shows should come from this sum, not from a settings field somebody filled in once.
The kitchen display is the product, the printer is a dependency
Owners buy an ordering app for the customer screen and then live with the kitchen screen. That is the wrong way round. A customer uses the menu for two minutes, standing still. The kitchen uses the ticket list for the whole service, at a distance, with wet hands, while something else is burning.
So: type readable from a metre away, a ticket that can be started and bumped without hunting for the control, a visible count of what is waiting, and an obvious difference between a new ticket and an amended one. Colour alone will not carry that difference on a screen behind steam.
The printer earns its own paragraph because it is the part that fails. Thermal printers jam, run out of paper mid ticket, drop off the network, and print tickets nobody picks up. If the printer is the only place an order becomes visible, a paper jam is a lost order and the customer is the one who tells you. Treat paper as an output of the ticket list, never as the ticket list itself. The rest of what a restaurant app does for the front of house follows the same rule: one record, many views.
The menu changes in the middle of service
At half past seven the sea bass runs out. In the room that is one word, 86, shouted once. In an app it is a state change that has to reach every open menu, every half filled cart and every order already paid for, and each of those wants a different answer.
The interesting case is the cart that already holds the item. Removing it silently is the worst option, because the customer pays for an order they did not check. Blocking checkout with an explanation is better. Best is letting the kitchen mark the item off with a scope: gone tonight, gone until Thursday, or available but slow. It also has to be reversible in one tap by somebody with flour on their hands, because the item usually comes back. If that needs a laptop in the office, nobody does it during service and the app spends the busiest three hours lying. A food truck app meets the same problem harder, since the whole menu can change between two lunch stops.
Calorie labelling once you have twenty locations
US menu labelling requirements apply to restaurants and similar retail food establishments that are part of a chain with 20 or more locations doing business under the same name and offering substantially the same menu items. Those businesses declare calories for standard menu items on menus and menu boards, keep written nutrition information available on request covering total calories, total fat, saturated fat, trans fat, cholesterol, sodium, total carbohydrates, sugars, fiber and protein, and display the statement that 2,000 calories a day is used for general nutrition advice, but calorie needs vary. The compliance date was 7 May 2018. Your app is a menu, so the rules follow it there.
Money, and the rule Apple actually applies
Two questions get conflated here. Whether your app can take payment at all, and what Apple requires you to use. Guideline 3.1.3(e) answers the second: if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. Food is consumed outside the app, so in-app purchase is the wrong mechanism and its commission does not apply to the order.
The first question is about you rather than Apple. Newly does not process card payments. Taking money means integrating a payment provider such as Stripe or Apple Pay, with your own account and that provider's rules on fees, refunds, chargebacks and disputes. That is real work with a real cost, and any tool implying otherwise is describing an integration rather than a capability.
Decide early whether money moves at order time or at collection. Paying up front kills no-shows and makes refunds your problem. Paying on collection keeps card handling out of the app entirely and turns the order into a booking, which is a legitimate and much cheaper product. Plenty of single site restaurants would be better off with the second and get sold the first.
App Store Review Guidelines, 3.1.3(e) goods and services outside of the app
What each way of taking an order gives the kitchen
| Option | Reaches the kitchen without retyping | Modifiers survive intact | You keep the customer | What it costs per order |
|---|---|---|---|---|
| A phone call | No | as well as whoever writes it down | Yes | staff time on the phone |
| A national marketplace | Yes | Yes | No | commission, set by them |
| Ordering on your website | usually | Yes | Yes | depends on the plugin |
| An app that emails the order | No | Yes | Yes | nothing extra |
| An app you build | Yes | Yes | Yes | your build plus payment fees |
Building one around your own kitchen
The platforms in this category are built for chains and priced accordingly, per site per month plus a cut, and the shape they assume is a predictable menu with a call centre behind it. A single restaurant with a wood oven, two collection slots a night and a rule that nothing goes out after the last table is seated needs a fraction of that, and needs three things the platform will not bend on.
Newly is an AI app builder. You describe the app you want, including how your kitchen actually fires tickets, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not a restaurant platform and does not compete feature for feature with one: no card processing inside it, no delivery network, no menu somebody else maintains for you. It is what you use when the platform is built for a business ten times your size and you want the ticket to look like your ticket.
The last piece is the loop back to the customer. An order that is ready and a customer who does not know it is a cold order, so telling a customer the order is ready is not a nice extra, it is the end of the transaction. Get that one message right before adding anything else.
Questions restaurants ask about online ordering apps
It has to carry instructions, not just items. Modifiers that change the cook, an allergen declaration in its own structured field, whether the order is collection or delivery, and a fire time the kitchen can actually meet. A cart stores a product and a quantity. An order stores what the kitchen has to do differently, and money leaks every time that detail arrives as free text.
Describe the way your kitchen actually takes an order
Write down what a ticket has to say, who reads it and when it fires, then build the ordering around that rather than around a menu screen.
Start building