🤖 Chrome on Android
The everyday case on an Android phone. Current versions, which is what a phone keeps itself on without anybody having to think about it — point the camera, tap the notification, read the menu.
Support · Browsers and devices
No app.
Just the browser they already have.
Your customer scans the sticker and your menu opens in whatever browser is already on their phone. This page is the honest version of that: what works, why a phone occasionally asks a question first, and what to do on the day a code will not open.
The customer side
Any current browser. No app, no account.
The ordering page is a web page, so the list of what works is really the list of browsers people already have. These are the families a scan actually arrives from.
💙 Samsung Internet
The browser a Galaxy opens by default, so a lot of customers never leave it. Same page, same behaviour — a scan from here is not a special case.
🍏 Safari on iPhone and iPad
Current versions. Scanning a sticker with the iPhone camera opens Safari and your menu, with nothing in between — no download prompt and no sign-in.
🧭 Chrome, Edge and Firefox on iPhone
All fine. On an iPhone most browsers draw the page with the same engine Safari uses, so if it works in Safari it works in the rest — which is why we do not keep a separate list for them.
💬 The browser inside another app
Plenty of customers arrive from a link in WhatsApp, Instagram, Facebook, Telegram, LINE or WeChat, and the little browser those open works. Some are stricter about storage than a full browser, so if a basket goes missing, use the app's own Open in browser and scan or tap again.
🕵️ Private and incognito windows
Work as normal. The basket lives in the phone's own browser storage, so with storage blocked it may not survive closing the tab — but an order that has been sent is already with your kitchen and is not affected by anything the phone does afterwards.
We do not print a minimum browser version. A number like that reads as a promise, and it is not one we could check against every phone that walks up to your counter. What the page needs is a browser from the last few years with JavaScript switched on — which is every browser above, kept up to date by the phone itself.
If a customer's phone is old enough that the page looks wrong, nothing is lost: your counter takes the order the way it always did.
On the shop's own network
Why a phone sometimes asks first
A table code usually points at your tablet, on your own network — not out to the internet and back. That is what keeps ordering working on the day the line drops, and it is also why a phone occasionally has a question before it shows the menu.
A bar that says the page is not secure
Reaching a tablet across the room, there is no padlock to have — a device on a shop network has no name on the internet to have one issued for. Nothing about the order leaves the building at that moment: it is a phone talking to a tablet a few metres away. The customer can carry on.
A prompt asking to reach a device on this network
Some browsers check before letting a page talk to something on the same network. Tapping Allow is what lets the menu load. Nothing is installed and nothing is granted beyond this page.
Either way the answer is the same, and it is worth having on a card by the till so staff can say it in one sentence: carry on, or allow it. If a customer would rather not, the three routes below still work — and one of them asks nothing of their phone at all.
For the technically minded
By default a printed table code opens the hub's own address on the shop's LAN, over plain HTTP on a port of its own — and if the merchant has published a public address, it carries that alongside in the fragment. A stall that has published none has a code with no fragment at all, because an alternate pointing back at the page's own origin would only invite a loop. The merchant can also choose to have the public address open first, with the LAN one carried instead.
http://192.168.1.42:8080/t/T12#alt=https://yourshop.example
The fragment is never put on the wire by a browser, which is the reason it lives there: the shop's private address stays out of the relay's access log, and the public hostname stays out of the hub's.
A private address — RFC 1918 space, handed out by the shop's router — has no public name, so no certificate can be issued for it and the page is served over plain HTTP. Browsers mark that Not secure in the ordinary way. It is accurate about the transport and misleading about the risk, which is why the wording above talks about the room rather than about the padlock.
The prompt is Private Network Access (Local Network Access in newer Chrome), which gates a request from a public page to a local-network address. Arriving from the printed LAN code the page is already local, so the usual case is no prompt at all.
The asymmetry is worth knowing if you are debugging a handoff. An HTTP page may fetch an HTTPS one, so a page served by the hub can check the public address is answering and only then move a customer across. The reverse is blocked twice over — mixed content, then Private Network Access — so an HTTPS page served through the relay cannot probe a plain-HTTP LAN hub at all. It can still navigate there, because a top-level navigation is neither, so that direction is offered to the customer as a tap and never taken automatically.
There is one automatic hop per session, and the count the two origins agree on is the one in the fragment — each keeps its own copy only as a fallback for a reload after the fragment has been scrubbed off the URL. Without a travelling count, two unhealthy addresses would bounce a phone between them for ever, each hop looking like a page reload and none of them producing food. After the first, the move is a button.
None of this needs anything done to a router. The hub dials out to the relay over a WebSocket, so there is no port forward, no VPN and no firewall rule to keep alive. Offline ordering has the rest of the shape.
Troubleshooting
If the code will not open
Three routes, in the order worth trying. The page offers the first two itself when it can see which one is available, so a customer usually gets a button rather than a diagnosis.
🌐 Try the online code
If your shop takes orders from outside, there is a second code for that address and it goes over the internet — so it opens on mobile data, from the queue outside or from the car park. When the page finds it cannot reach your kitchen, it offers the move itself:
Try ordering online 🌐
📶 Or join the shop's Wi-Fi
A table code points at the tablet in your shop, and a phone on mobile data is not on that network. Joining the Wi-Fi and scanning again is the whole fix. Coming the other way, from the online address, the page offers it as a tap:
Try the shop's Wi-Fi 📶
🛎️ Or order at the counter
The route that asks nothing of the customer's phone. Staff ring it into the same order book, with the same numbers and the same kitchen queue — a counter order and a scanned one are the same thing downstream. The page says so rather than leaving somebody guessing: the stall is probably still open — please order at the counter.
This is why OrderLah prints two codes. A code that names only your own network will not open on mobile data, and a code that names only the public address needs your internet to be up. So the table code opens your tablet directly and carries the online address with it, and the separate online code covers the customer who was never on your Wi-Fi to begin with.
Your side
An Android tablet, and nothing to buy from us
The customer side needs a browser. Your side needs one tablet to be the hub, and whatever else you already have can join it.
- The hub: an Android tablet running Android 7.0 or newer. This is the one that holds your menu, mints the order numbers and stores every order — so it is the one worth having on a charger.
- Counter tablets, waiter phones and kitchen screens: Android 7.0 or newer too. They pair to your hub over the shop's own network and take a role when they join.
- A screen on the wall shows a web page. The display boards — the queue, the collection list — are pages your hub serves, so a screen joins by opening its address and waiting to be approved on the hub. Each screen is its own row afterwards, so one can be taken off the wall without disturbing the others.
- No OrderLah hardware. We do not sell tablets, printers or terminals, and there is no OrderLah box you have to buy to make any of this work.
- No supported-device list to check yourself against. The counter grid is solved from the width it is actually given, so a bigger screen is more dishes at the same comfortable size rather than a model number to look up.
One licence covers the outlet rather than the tablet, and the devices paired to your own hub are unlimited — the counter, the kitchen screen, the waiter's phone and the display on the wall are all on the one licence that shop holds. Pricing has the figure, read live so it cannot go stale.
Still odd?
If something looks wrong
Four things, in order, and the last one is a person. None of them can lose an order that has already been sent.
- Reload the page. Phones on a busy shop network drop connections mid-tap, and a reload is usually the whole of it. Your basket is kept.
- Scan the code again. A fresh scan starts a clean session. A basket left behind by a tab you closed is moved across to the new one rather than copied, so you never end up holding two of the same order.
- If you arrived from a link inside another app, open it in the phone's own browser. There is usually an Open in browser item in that app's menu, and it clears up the handful of cases where a small in-app browser is stricter than a full one.
- Ask staff. They can see the kitchen queue on their own screen, and they can ring the order in at the counter. It reaches the same place.
The thing worth knowing while you are doing any of that: sending the same basket twice is recognised as the same order, so a retry after a dropped connection does not put two of anything in the kitchen. 🙂
Reliability
"Is OrderLah down?"
Usually the more useful question is whether your own hub is up, because the part your shop runs on is on your own counter. Here is how to tell what is actually wrong.
The shop
Your hub tablet is the server. If the counter and the Order Board are talking to each other, your shop is up — whatever is happening anywhere else. The hub's own home screen says whether it is reachable on your network, and it is the only screen that can answer that, because it is the only machine that knows.
Ordering from outside the shop
This one does go over the internet, so it can be down while the shop is perfectly fine. When it is, the counter and the table codes on your own network carry on and only orders from elsewhere wait. The matrix sets out which is which.
What we deliberately do not publish
There is no OrderLah status page, and that is a decision rather than an omission. The thing you need up is your tablet, and we cannot see it — by design, since there is no copy of your shop on our servers to watch. A dashboard of ours would be reporting on the one piece you can trade without, which is worse than no dashboard because it looks like an answer.
If something is wrong and this page has not explained it, email us — a real person reads it, and telling us what your tablet says on its own screen is the fastest way to a useful reply.
Start today, or see it first.
The trial is the whole product for 14 days, with no card and nothing to cancel. The demo is the real flow with pretend data — order from a table, watch it hit the kitchen, move it to ready. No sign-up, no email, no salesperson.
The customer side
Another app?
No thanks.
Your customer is hungry, standing up, and holding a phone with 3% battery. They are not downloading anything. They scan the QR code and your menu opens in the browser that is already on the phone.
To be straight about it: OrderLah does have an app — the one you run the stall on, on your own tablet. It's the ordering side that needs nothing installed.
- App Store
- Play Store
- Create account
- Forgot password
- Update app
- Scan
- Order
- Eat
Start free
Fourteen days free. No card.
Every new outlet gets a full 14-day trial — the whole product, not a cut-down version — with nothing to cancel at the end of it. You do not need to be invited, approved or called back: create the account, put it on your tablet, and go. What a licence costs afterwards is on the pricing page, in your own currency, taken straight from the price list checkout actually charges.
- Your 14 days start when you activate on your tablet — not when you sign up.
- Turn on the parts you want — QR only, counter only, or the lot. It is all in the settings.
- Tell us what is missing and it changes the app. We do read it.
Already set your shop up? Sign In.
Optional
Rather have a hand with it? 🤝
Nothing here is a gate — the trial above is open right now. But if you'd like somebody to walk your stall through it, tell us a bit and we'll get in touch. Takes about a minute; fields marked are required.
Got it — talk soon 🎁
Your reference is —. No need to wait for us, though — the trial is open right now.
Start 14-Day Free Trial