Most restaurants end up running their menu in four places at once. The printed menu, the website, the POS, and two or three delivery apps. Change one price and three of them are now wrong.
That is not a design problem. It is an integration problem, and it is the part of a restaurant website project that most agencies quietly skip. This guide covers how menu data, delivery platforms and your POS should connect, what it costs to run, and when a direct ordering channel is worth building.
If you are starting earlier than this, our guide to the pages a restaurant website needs covers the structure. This post picks up where that one ends.
One Menu, Four Places: Why It Breaks
A typical mid sized restaurant publishes its menu to the website, the POS, and two to four aggregators. Nobody owns the master copy.
The result is familiar. An item is sold out on the app but live on the website. A price rose in the POS last month and the aggregator still shows the old one, so you absorb the difference on every order. A dish was discontinued and is still taking orders somewhere.
Each of those is a refund, a bad review, or a staff member on the phone during service.
The fix is to pick one system as the single source of truth and push outward from it. Usually that is the POS, because it already holds the item codes your kitchen uses.
The Three Ways a Restaurant Takes Orders
Before integrating anything, be clear about which channels you are actually running.
Aggregator orders
Swiggy and Zomato in India. Talabat, Deliveroo and Careem in the UAE. DoorDash, Uber Eats and Grubhub in the USA. Just Eat and Deliveroo in the UK.
They bring volume and they take a commission on every order. Commission varies by market, by plan, and by whether you use their riders. Read your own contract rather than an industry average, because the number that matters is yours.
Direct online ordering
Orders placed on your own site or app, paid through your own payment gateway, fulfilled by your staff or a third party courier you book yourself.
No commission. You pay a payment gateway fee instead, which is a fraction of an aggregator cut. The cost is that you have to generate the demand yourself.
Table and pickup
Dine in orders, QR code ordering at the table, and collection orders. These are usually the highest margin orders in the building and the ones most restaurant websites handle worst.
| Channel | Who owns the customer | Typical cost per order | Effort to run |
|---|---|---|---|
| Aggregator delivery | The platform | Commission, varies by market and plan | Low, they drive demand |
| Direct delivery from your site | You | Payment gateway fee plus courier cost | High, you drive demand |
| Direct pickup or collection | You | Payment gateway fee only | Medium |
| QR ordering at the table | You | Payment gateway fee only | Low once set up |
The honest position is that you want both. Aggregators for reach, direct ordering for margin and for owning the customer record.
How Menu Sync Actually Works
There are three routes, and the right one depends on how many outlets and platforms you run.
Manual. Someone updates each platform by hand. Viable for one outlet and one or two platforms. It fails the moment you have three outlets.
Middleware. A layer that sits between your POS and every delivery platform, pushing menu changes outward and pulling orders inward into one tablet or one printer. This is what most multi outlet restaurants use.
Direct API. Your developer connects your system to each platform’s partner API individually. More control, more build cost, and you maintain each connection as those APIs change.
The thing nobody mentions: aggregator menus are not identical in structure. Modifier groups, combo rules and item availability behave differently on each platform. A sync that works perfectly for a simple menu can mangle a menu with heavy customisation. Test with your most complicated item first, not your simplest.
Stock and Availability Is the Integration That Pays
Price sync gets the attention. Availability sync saves more money.
When the kitchen runs out of an item at 8:40 PM on a Saturday, that item needs to disappear from every channel within seconds, not at the next manual update. Otherwise you spend the rest of service cancelling orders, and cancellations hurt your rating on every platform that measures them.
Build the availability switch so a kitchen staff member can hit it from a tablet without opening three apps. That single feature is often the strongest argument for integration in the first place.
What It Costs to Build and to Run
Build costs for the website and ordering layer, as planning ranges:
| Scope | Build cost (USD) | Build cost (INR) |
|---|---|---|
| Website with menu, booking and links out to aggregators | $1,200 to $3,000 | 1 to 2.5 lakh |
| Add direct online ordering with payment | $2,500 to $6,000 | 2 to 5 lakh |
| POS plus aggregator sync through middleware | $1,500 to $4,000 setup | 1.25 to 3.5 lakh |
| Custom ordering app for iOS and Android | $8,000 to $20,000 | 6.5 to 16 lakh |
Running costs are the part restaurants underestimate. Expect a monthly middleware subscription per outlet, a payment gateway percentage on direct orders, hosting, and the aggregator commissions themselves. We broke down the recurring side of this in our post on ecommerce running costs, and most of it applies directly.
A custom app is rarely the right first step. Build direct ordering on the website, prove people use it, then consider an app once you have repeat customers worth retaining.
Make Your Menu Readable to Google
Your menu should exist as real text on a real page, not as a PDF and not as an image. Then mark it up with structured data so search engines can read it. Google’s guidance for restaurants sits under its local business structured data documentation, and the vocabulary itself is defined at schema.org.
Done properly, this feeds your opening hours, location, price range and menu into Google and your Business Profile. It costs a developer an afternoon and it is the cheapest organic win available to a restaurant.
Payments and Refunds, Done Once
Direct ordering means you own the payment flow, which means you own the refund flow too.
Decide these before the build, not after the first failed order:
- Which gateway, and whether it supports partial refunds for a single missing item
- Whether you take payment on order or on dispatch
- What happens to an order if payment succeeds and the kitchen rejects it
- Who can issue a refund, and from which screen
- How a failed payment that still debited the customer is reconciled
Refunds are where small restaurants lose trust fastest. Build one screen where a manager can see the order, the payment, and a refund button.
Order Notifications That Staff Actually See
An order that arrives in an email inbox during a Friday rush does not exist.
Direct orders need a loud channel: a dedicated tablet with sound, a thermal printer that fires automatically, or a WhatsApp message to the duty manager. We cover the mechanics of the last one in WhatsApp integration for websites.
Whatever you choose, test it at full volume in a noisy kitchen before launch.
Owning the Customer Record
The commercial argument for direct ordering is not really the commission. It is the data.
On an aggregator, the customer belongs to the platform. You do not get their number, you cannot message them, and you cannot tell a first time order from a fiftieth.
On your own channel, you can. Repeat order rate, favourite items, average spend, and a reason to send a message on a quiet Tuesday. That is a CRM problem, and it is worth setting up from the first order rather than retrofitting a year later. We build this into custom CRM systems so that order history and customer record are the same object.
Mistakes We See Most Often
- Treating the menu as a design asset instead of structured data
- Launching direct ordering with no plan to drive traffic to it, then concluding nobody wants it
- Syncing prices but not availability
- No delivery radius logic, so an order arrives from 40 minutes away
- Hiding the pickup option, which is the highest margin order you can take
- Choosing middleware before checking it supports your POS and your country’s aggregators
How We Build Restaurant Systems
We start by asking which channels you run today and which one you want to grow, because that answer decides whether this is a website project or an ordering platform project.
A typical build runs three to six weeks for the site and ordering layer, with integration work scoped separately once we know your POS and which aggregators you are on. If a native ordering app is genuinely the goal, that is app development and we quote it as a second phase so the website is earning before the app starts.
Frequently Asked Questions
Almost never, at least not at first. Aggregators bring discovery you cannot replace overnight. The better strategy is to run both, then use packaging inserts, QR codes and staff prompts to move repeat customers to your direct channel where the margin is better.
You can start without one if you have a single outlet and a stable menu. Once you have two or more outlets, or a menu that changes weekly, manual updates start costing more in errors than the integration costs to build.
With established middleware and a supported POS, a straightforward single outlet setup is usually days rather than weeks. Complex modifier groups, multiple outlets or an unsupported POS can push it to several weeks.
Only after direct website ordering is already working. An app is worth building when you have enough repeat customers that saving them a step and holding their card details produces real repeat orders. Before that it is an expensive menu.
In some markets Google supports ordering through partners linked to your Business Profile. Keeping your hours, location and menu accurate with structured data is the prerequisite either way.
Live stock and availability sync. It stops cancellations during service, which protects your rating on every platform at once.
Final Thoughts
Restaurant websites are rarely judged on how they look. They are judged on whether the price is right, the item is actually available, and the order reaches the kitchen.
Pick one source of truth for the menu, sync availability before you worry about anything else, run aggregators and direct ordering side by side, and build the customer record from the first direct order.
If you want a straight answer on whether your current setup needs integration or just tidying, tell us what you are running, your POS, your outlets and your platforms, and we will give you a scope and a number without a sales call.
