Restaurant Mobile App: Ordering, Loyalty & QR Menus

A restaurant mobile app pays for itself on repeat customers, not on delivery. Marketplace commissions run 20% to 30% of the order, while median restaurant profit margins sit at 2.8% to 4%. In the worked scenario below, a $60,000 build breaks even at roughly 420 to 1,500 shifted orders a month, depending entirely on who carries the food.

That last clause is where most advice falls apart. "Build your own app and escape commissions" treats a delivery marketplace as a tax. It isn't. It is two products bundled together: demand and logistics. Your own app can take over the second one, and it can only partly take over the first.

This restaurant mobile app guide is written for the operator doing the arithmetic: which module solves which problem, where an order breaks before it reaches the kitchen, when a loyalty scheme actually changes behavior, and what the budget buys line by line.

Table of Contents

• The Commission Math Behind Every App Decision
• Where the Savings Are, and Where They Vanish
• Marketplaces Buy Discovery, Your App Buys Frequency
• What Diners Actually Say They Want
• The Ordering Module: Menus, Modifiers and Zones
• Payments, Fees and Checkout Transparency
• POS Integration: Getting the Ticket Into the Kitchen
• Loyalty That Changes Behavior, Not Just Points
• QR Menus, Web Ordering and Native Apps
• One Location or Twelve: Not the Same App
• Budget Framework, Line by Line
• The First 90 Days After Launch
• Pre-Launch Checklist

The Commission Math Behind Every App Decision

Start with the only number that matters: what lands in your bank account from a $32 ticket.

Unlike most marketplace pricing, Uber Eats publishes its merchant rates, so you can check the arithmetic rather than trust a sales call. Its US pricing page lists three marketplace plans — a 20% Lite fee, a 25% Plus fee and a 30% Premium fee — with a lower entry rate in selected cities. Pickup orders carry a 7% fee with validated in-store pricing and 10% without it. Self-delivery, where your own staff drives, is billed at 15%. And the number that reframes the whole debate: orders through the operator's own storefront are charged 2.5% plus $0.29 per order.

That is the same company quoting you 30% for a marketplace order and 2.5% for the identical order placed on your own channel. The gap is not a technology cost. It is the price of demand.

Now set those percentages against profitability. The National Restaurant Association's 2026 State of the Restaurant Industry report puts median income before taxes in 2024 at 2.8% of sales for fullservice restaurants and 4% for limited-service, down from 4% and 6% respectively in 2019. Industry sales are forecast at $1.55 trillion in 2026, a 4.8% rise, though real growth after inflation lands at just 1.3%.

Read those two facts together. A 30% commission is roughly eight to eleven times your net margin on that order. The order is not unprofitable because of it — commission comes out of gross, not net — but it does mean a marketplace order and a direct order are two completely different businesses wearing the same logo.

Where the Savings Are, and Where They Vanish

Work through a single shifted order and the case for a restaurant mobile app stops being a slogan and becomes arithmetic.

Assume a $32 average ticket, card processing at 2.9% plus $0.30, and an app that costs $60,000 to build and $12,000 a year to run. Amortized across 24 months, that is $3,500 a month to cover.

• A marketplace delivery order becomes an app pickup order. You save $9.60 in commission and pay $1.23 in processing. Net gain $8.37. Break-even: around 420 orders a month, or 14 a day.
• A marketplace delivery order becomes an app delivery order with your own driver. Same $8.37, minus roughly $6 in loaded driver cost per drop. Net gain $2.37. Break-even: around 1,480 orders a month, or 49 a day.
• A marketplace delivery order becomes an app order with on-demand white-label couriers. Uber Direct starts at $7.99 per delivery on the same published page. Net gain shrinks to roughly $0.38 — a rounding error.
• A marketplace pickup order becomes an app pickup order. You save $2.24 and pay $1.23. Net gain $1.01, which alone will not fund a build.

The conclusion is uncomfortable and worth saying plainly: the money is not in delivery. If customers come to you, a restaurant mobile app is a strong financial decision. If a third party has to drive, the economics collapse toward break-even, because most of that 30% was genuinely buying a driver.

So sequence the build accordingly. Phase one: pickup, dine-in ordering, pay-at-table and loyalty. Phase two: delivery, once you know your repeat volume. You can test your own numbers in the app cost calculator before committing to scope.

Marketplaces Buy Discovery, Your App Buys Frequency

Leaving the marketplaces entirely is the wrong call for most independents. The workable arrangement is a division of labour: the marketplace introduces you to a stranger, the app brings that person back.

Operator behaviour already reflects this split, and it explains why a restaurant mobile app sits alongside the marketplaces rather than replacing them. In the same NRA research, 62% of limited-service and 40% of fullservice restaurants offer delivery. Among limited-service operators, 38% let customers order both through a third party and directly, while only 15% are third-party-only. Most operators who offer delivery, 69%, say it creates opportunities rather than problems — but 31% say the reverse, and they name high fees, chargebacks, limited control over timing and plain profitability as the reasons. Fullservice operators feel it more sharply, at 37%.

That split is the whole strategy in one statistic. Delivery marketplaces are good at the thing you cannot easily buy — being in front of a hungry stranger at 7pm — and bad at the thing you can build, which is a relationship with someone who already likes your food.

There is a second asset most operators undercount: data. On a marketplace order, who ordered what, how often they return and which promotion moved them largely stays with the platform. On your own channel you own that history, and it drives menu decisions, prep planning and promotion timing. We walked through the same direct-versus-intermediary logic on the lodging side in hotel booking engines; restaurants differ only in having smaller baskets and far higher frequency, which makes the case stronger, not weaker.

What Diners Actually Say They Want

Demand for a direct channel is not a hypothesis. The NRA's consumer research is unusually direct on this point.

74% of consumers say they would order and pay using an app on their smartphone if a restaurant in their area offered it. By age, that reaches 89% of millennials, 80% of Gen Z adults and 80% of Gen X, falling to 54% of baby boomers. Ordering through a restaurant's own website polls at 70%, a self-service kiosk at 68% and a tablet at the table at 67%.

On delivery specifically, the gap between habit and preference is striking. 75% of delivery customers ordered through a third-party service in the past six months, yet 56% say they would rather order directly from the restaurant. Among baby boomers that preference hits 80%; among Gen Z adults it inverts, with 56% preferring a third-party service. When asked who should hand over the bag, 44% prefer a restaurant employee and only 26% prefer a third-party driver.

Two practical reads. First, the direct channel is not a hard sell — a majority already prefers it and simply has no convenient way to use it. Second, your customer mix decides your roadmap: an older, local, high-frequency base will adopt a restaurant mobile app quickly, while a young, delivery-first base may genuinely prefer the marketplace and need a sharper incentive to move.

The Ordering Module: Menus, Modifiers and Zones

The ordering module is the heart of a restaurant mobile app and the part most often underscoped. Putting a menu on a screen is easy. Putting a menu on a screen in a form the kitchen can actually produce is not.

Seven things decide whether this module works:

1. Modifier and forced-choice logic. "Medium pizza, two toppings, choose a drink" means dynamic pricing rules. Retrofitting these costs several times what designing them upfront does.
2. Stock and sold-out items. An item that ran out at 9pm and stays on the menu converts every order into a refund call.
3. Delivery zones and minimums. Polygon-based zones cause far fewer disputes than postcode lists, and each zone needs its own fee and minimum basket.
4. Prep time that flexes. When the kitchen is slammed, the quoted time must stretch automatically. A hard-coded "30-40 minutes" loses its rating on the first busy Saturday.
5. Scheduled ordering. Taking a lunch order at 10am for 12:15 pickup generates loyalty by itself in any office district.
6. Separate dine-in, pickup and delivery flows. Three journeys share one basket screen but need different validation.
7. Address accuracy. Map pins, unit and door-code fields, saved addresses. A bad address burns your margin, not the driver's.

If live tracking is in scope, the mapping and geolocation side carries its own cost and battery trade-offs, which we covered in location-based app development.

Payments, Fees and Checkout Transparency

Three decisions sit together here: which methods you accept, who processes the money, and whether app store commission applies.

Store commission. You are selling physical food, not digital content, so in-app purchase rules do not apply and you use a normal payment gateway instead. That distinction decides a meaningful slice of your unit economics, and we unpacked where each model applies in in-app purchase or payment gateway.

Method coverage. Saved cards, Apple Pay and Google Pay, cash on delivery where you still accept it, and wallet balance if you run stored value. Saved cards plus a wallet-based express checkout are what turn a second order into two taps, and two-tap reordering is the single strongest retention mechanic a restaurant mobile app has.

Fee transparency. Hiding the delivery fee inside menu prices is a false economy. If a customer cannot see item total, delivery fee and any service charge as separate lines, they abandon the basket — and abandoned baskets are the quiet, unmeasured loss of every direct channel. State the fee plainly and zero it above a threshold. That grows average order value and makes the comparison against marketplace pricing favour you, since marketplace menu prices are often marked up to absorb commission in the first place.

Compliance. Consumer law in the US, UK and EU converges on one requirement: the total price a customer will pay must be clear before they commit, with mandatory fees disclosed upfront rather than revealed at the final step. Saved addresses, phone numbers and order history are personal data under GDPR and CCPA, so retention periods, deletion flows and a lawful basis belong in the data model rather than in a policy page nobody reads.

POS Integration: Getting the Ticket Into the Kitchen

This is where projects fail quietly. The app works, the payment clears, the customer is happy — and the ticket never reaches the point-of-sale system. A staff member retypes it, the queue scrambles at peak, item mappings drift and your sales reporting splits in two.

A sound integration is two-way. Your menu, items and modifier tree bind to the POS catalog, and orders write into the POS order service. The established platforms model it exactly this way: Square's Orders API documentation describes centralizing orders from online, in-person and in-app channels into one system, with the catalog mapped programmatically beneath it.

Questions to settle before anyone writes code:

• Does your POS expose a documented API, or only file exports and a nightly batch?
• How often does catalog sync run, and which side owns the price? Pick one source of truth — managing prices in two places guarantees drift.
• What happens when a write fails? Is there a retry queue, an audible alert and a visible failed-order list?
• What format does your kitchen display system or printer expect?
• Do refunds and voids flow back into the POS as corrections?

If the terminology is new, API integration explained covers the basics. One hard-won piece of advice: do not defer POS integration to phase two. Teams assume they will cope with manual entry for a while. In practice the kitchen quietly sabotages the channel, because the app made their shift harder.

Loyalty That Changes Behavior, Not Just Points

Loyalty is the easiest module in a restaurant mobile app to code and the hardest to design. "5 points per $20" ships in two days and changes nothing.

The demand signal is strong. In the NRA research, 70% of delivery customers say loyalty program membership matters when choosing a restaurant, rising to 77% among millennials; for takeout it is 65% and for drive-thru 64%. Operators see the effect unevenly: 60% of limited-service operators say technology has significantly affected their loyalty programs, versus just 33% of fullservice operators — a gap that tracks visit frequency almost perfectly. Value sits right beside loyalty, with 81% of diners saying a discount or value promotion matters when choosing a restaurant for delivery.

Four structures reliably work:

• Frequency-based. "Your fifth coffee is on us." Strongest for daily-habit items, because the reward arrives quickly.
• Basket-building. A dessert or drink above a spend threshold. Make the reward a high-margin item, not a cheap one.
• Demand-shifting. Double points during dead hours. This balances the kitchen and expands capacity for free.
• Win-back. A single-use offer to anyone who has not ordered in 45 days. The highest-return mechanic and the least often built.

Two technical requirements decide whether any of them land: the balance must be visible on every screen, and redemption must be one tap. Making a customer remember a promo code produces friction, not loyalty. The reminder layer needs the same care — permission, frequency and timing — which we set out in push notification strategy. In food, a notification sent at the wrong hour is the most common cause of uninstalls.

QR Menus, Web Ordering and Native Apps

These three tools solve different problems, and buying the wrong one wastes most of a budget. Naming your actual problem is half the work.

The sensible order of adoption is QR menu, then web ordering, then a restaurant mobile app. Running it backwards — a business with no repeat customers commissioning an app first — means paying for software nobody downloads.

Two nuances are worth knowing. Once a QR menu accepts orders at the table, it stops being a menu and becomes an ordering channel, which means it needs the same POS integration discussed above. And a QR code on the table is the cheapest app install channel you will ever have: a screen offering a loyalty balance and a first-order incentive converts far better per dollar than paid install campaigns.

One Location or Twelve: Not the Same App

A single site and a twelve-site group order the same restaurant mobile app and build a different system. The difference explains much of the cost spread.

A single location needs one menu, one delivery zone, one till, one set of opening hours. Loyalty is spent in one place. A modest admin panel runs the whole thing.

Multiple locations add a stack of layers: location selection and nearest-site logic, per-site pricing, per-site stock and hours, routing each order to the correct kitchen, whether loyalty balances cross locations, separate reporting and permissions for franchisees. Each one is a screen and a rule set.

In practice, once the count passes three, one decision dominates: central menu control or local autonomy? Central control gives consistency but blocks local promotions. The hybrid — a locked core product set with an open local campaign slot — works most often, but it demands a permission matrix designed upfront. Adding that matrix later means rewriting user roles and every admin screen, which is the most expensive retrofit in multi-site work.

Budget Framework, Line by Line

The ranges below are Master Web's own indicative bands, not an industry survey. Scope, integration count and design depth move them in both directions.

Recurring annual costs cover hosting and push infrastructure, developer accounts, gateway fixed fees, maintenance and platform compliance updates. Do not treat this as noise: it typically runs 15% to 20% of the first-year build, and the drivers are broken down in app maintenance costs.

Operators are funding this category deliberately. Eight in ten told the NRA that restaurant technology provides a competitive advantage; six in ten plan technology investments aimed at the guest experience in 2026, and 54% plan to invest in front-of-house productivity. Meanwhile 26% already use tools incorporating AI, mostly in marketing rather than order taking.

The First 90 Days After Launch

Shipping a restaurant mobile app is the start of the work, not the end. The main reason restaurant apps fail is not bad software — it is an app nobody installed.

Installs, days 1-30. Your cheapest acquisition channel is the table itself: a QR code, a till-screen prompt, a card in the takeaway bag, a flyer that travels with the driver. Position the first-order incentive as the reward for installing. An announcement to your existing email and SMS list beats paid media on day one.

Three levers drive installs and they work together: a concrete incentive at the moment of install, the physical placement of the prompt, and speed on the second order. The third is the one most often neglected — an app installed for a discount but slow to use becomes a dead icon within a week.

Second orders, days 30-60. A single-order user is worth nothing. One reminder triggered after the first order, plus a loyalty balance notification, largely determines the second-order rate. The metric to watch is not downloads but second-order rate.

Habit, days 60-90. Weekly active users, order frequency, average basket per channel and the share of orders shifted off marketplaces. Without those four you cannot compute payback at all. How to instrument them is covered in mobile app analytics.

One warning: in the early months your own promotion must beat the marketplace promotion. Otherwise customers compare prices and go back to the commissioned channel. Passing part of the commission you no longer pay back to the customer is the most profitable marketing you can buy.

Pre-Launch Checklist

1. Menu, modifier tree and prices match the POS catalog exactly.
2. Failed POS writes enter a retry queue and trigger an audible alert.
3. Sold-out items drop off the menu automatically and can be restored in one tap.
4. Quoted prep time flexes with kitchen load.
5. Delivery zones are mapped as polygons, each with its own fee and minimum.
6. Payment tested live: successful charge, declined card, full refund, partial refund.
7. Pay-at-table and cash-on-delivery flows tested separately.
8. Loyalty balance visible everywhere; rewards apply in one tap.
9. Total price, fees, cancellation terms and privacy notice reachable inside the app.
10. Store requirements reviewed: account deletion flow, permission strings, reviewer test account.

That last item causes more delay than operators expect; the recurring reasons submissions bounce are collected in app store rejection reasons.

Frequently Asked Questions

Does a restaurant mobile app eliminate delivery commissions?

No. A restaurant mobile app ends commission on customers who already know you and order repeatedly; discovery still runs through marketplaces, search and maps. The realistic goal is moving your repeat orders to your own channel, not all of your orders.

How many orders a month does an app need to pay for itself?

In this guide's scenario — a $32 average ticket, a $60,000 build amortized over 24 months plus $12,000 a year to run — break-even lands near 420 orders a month if customers collect, and near 1,480 if your own staff delivers. Run the numbers with your own ticket size and contract rate, and always include driver cost.

Why does delivery wipe out most of the savings?

Because a large part of a 20-30% marketplace commission is genuinely paying for a courier, not for software. Published rates show self-delivery billed at 15% and on-demand white-label delivery starting around $8 per drop, so once you pay someone to drive, the gap between channels narrows to very little.

What is the difference between a QR menu and a mobile app?

A QR menu replaces a printed menu and shows the menu to a seated guest, with ordering still handled by staff. A mobile app is a repeat-purchase channel: saved cards, saved addresses, loyalty balance and push messaging. A QR menu takes days to deploy; an app takes 8 to 20 weeks.

Can an ordering app work without POS integration?

Technically yes, operationally poorly. Staff retype every ticket, errors and delays climb at peak, and reporting splits across two systems. In our experience the bigger risk is cultural: without integration the kitchen never adopts the channel, and it dies quietly.

Which loyalty mechanics actually drive repeat visits?

The ones with a short path to the reward: frequency rewards such as a free fifth coffee, a high-margin item above a spend threshold, double points during dead hours, and a single-use win-back offer after 45 inactive days. Complex percentage-accrual point systems rarely change behavior.

Is an app worth it for a single-location restaurant?

It is worth it if you have repeat customers, and premature if you do not. A single site selling daily-habit items such as coffee, lunch sets or bakery goods reaches payback faster than a multi-site delivery operation, because frequency is high and there is no driver cost.

Should we build separate iOS and Android apps?

For restaurant ordering, a cross-platform codebase shipping to both stores is usually sufficient; ordering and payment flows do not stress device hardware. Native work earns its cost when advanced live tracking or heavy background location processing enters scope. Launching on both stores together also costs less than adding the second platform later.

Building a restaurant mobile app is a channel decision dressed as a technology decision. Put three numbers on the table first: how many customers order from you more than once a month, your average ticket, and the commission rate in your current marketplace contract. Those three numbers decide the payback threshold for a restaurant mobile app. Below it, a QR menu and a web ordering page earn more than an app will. Above it, every month you delay is being invoiced to you as commission.

To pressure-test your own numbers, assess how integration-ready your current POS is, and scope a realistic phase one, take a look at our mobile app development service and get in touch with your menu and site structure.