Cloud-based restaurant POS: what 'cloud' buys you, and what happens when the Wi-Fi drops

Every restaurant POS on the market calls itself cloud-based, which means the word has stopped carrying information. It is used to describe three architectures that behave completely differently in the one situation that matters — when the connection drops halfway through a Saturday service.

This is what "cloud-based" actually covers, what it genuinely buys you, what it costs, the test to run before you sign anything, and what changes if you decide to build instead.

Three architectures, one word

Browser-only. The till is a web page. Every tap is a request to a server somewhere else, and the terminal holds nothing of its own. This is the purest cloud POS and the most common among newer, cheaper products, because it is by far the easiest to build and to update.

When the connection fails, it stops. Not degrades — stops.

Local-first with sync. The till runs against something on the premises — an app with its own local store, or a small server in the back office — and pushes to the cloud continuously. The cloud is where reporting, multi-site consolidation and configuration live; the till does not depend on it to take an order.

When the connection fails, service continues and the backlog syncs later. This is what most established restaurant POS products actually are, regardless of how the marketing describes them.

Hybrid caching. A browser-based till with an offline cache — a service worker holding the menu and queueing orders locally. It is genuinely better than browser-only and genuinely weaker than local-first, and the difference shows up in the details: how long the cache is valid, what happens to an order placed on two terminals while both were offline, and whether the kitchen screen is in the cache too.

Almost every product sits in one of those three. Which one you are buying is rarely stated on the pricing page, and it is the most consequential thing about the product.

The offline question is the whole decision

"Works offline" is not a yes-or-no answer. There are six separate capabilities and products support different subsets:

Take an order. The easiest, and the one everyone means by "offline mode".
Fire it to the kitchen. Needs the kitchen screen to be reachable without the internet, which means the till and the KDS have to find each other on the local network. Many hybrid systems fail here — the order is captured and the kitchen never sees it.
Take a card payment. Almost never truly offline. Card authorisation is an online operation by definition. Some terminals will store-and-forward within a floor limit, which is a real feature with real risk: you are accepting the card without knowing if it will authorise.
Print a receipt. Depends whether the printer is driven locally or from the cloud. Cloud printing is common and it is the second thing to fail.
Close a shift. Frequently unavailable offline even where ordering works, because the reconciliation runs server-side.
Look anything up. Yesterday's takings, a customer's tab, a reservation — all typically gone.

The honest summary: most "offline mode" claims mean capability 1, sometimes 2. That may be fine — taking orders on paper for twenty minutes is survivable, and losing the ability to take card payments is a problem no POS architecture can solve. But you should know which you are buying before the night it happens, not during.

What cloud genuinely buys

It is worth being fair about this, because the offline discussion makes cloud sound like a liability and it is not.

Multi-site consolidation. If you run more than one venue, this is the single strongest argument. Head office sees everything; each site sees its own. Doing that well on-premise is a real engineering project.
Updates that actually happen. On-premise systems drift into years-old versions because updating them means someone visiting. Cloud products do not have that problem, which is also a security argument.
Reporting from anywhere. Reading last night's takings from home is a genuine quality-of-life improvement, and it is the feature owners cite most.
Hardware independence. A browser till runs on whatever you already own, and a broken terminal is replaced by any other device rather than by a service call.
Backups you do not have to think about. The on-premise equivalent is a job somebody has to own, and usually nobody does until the first failure.

What it costs

Per-terminal pricing compounds. The headline monthly price is usually per till. A four-station dine-in venue is four times the number you were quoted, and the second location doubles it again. This is where cloud POS becomes expensive relative to a one-off purchase, and where multi-site operators start doing the build-versus-buy arithmetic.
Your internet becomes a single point of failure in a way it was not before. Worth pricing a second connection, which is cheaper than an evening of paper tickets.
Your data lives with the vendor. Ask what you can export and in what format before you have three years of order history in it. A system you cannot leave is a worse trap than an expensive one.
The roadmap is not yours. If they deprecate the module your venue depends on, that is your problem to absorb. This is the ordinary cost of renting a workflow, and it is fine right up until it is not.

Which hardware is tied to the cloud

What survives an outage is decided almost entirely by where each device gets its instructions, and this is rarely on a spec sheet. Ask about each one individually:

Receipt printer. Driven locally over the network, or from the vendor's servers? Cloud printing is common because it is simple to support, and it is one of the first things to go.
Kitchen display. If the KDS is a browser tab pointed at the same cloud service as the till, the two cannot talk without the internet even though they are four metres apart.
Cash drawer. Usually opened by the receipt printer, so it inherits the printer's answer. A drawer you cannot open is a small problem that feels enormous at the time.
Card terminal. Needs its own connection regardless. If it is on the same Wi-Fi as everything else, you have one failure not two — a terminal on mobile data is the cheapest resilience you can buy.
Label and order printers at stations. Same question as the receipt printer, usually the same answer, and usually forgotten until a bar ticket does not appear.

The pattern worth noticing: a venue can be sold "offline mode" and still lose the kitchen, the receipt and the drawer, because only the till was ever considered.

What to have ready for the night it happens

Every venue loses its connection eventually, and the difference between an inconvenience and a disaster is whether anyone planned for it. This costs nothing to prepare:

Know your degradation, in writing, on the wall. Which of the six capabilities above still work. Staff improvising during an outage is how orders get lost.
Paper tickets and a pen, somewhere findable. Duplicate books are better than blank paper, because the kitchen keeps one half and you keep the other — which is your reconciliation afterwards.
A card terminal on mobile data, independent of the venue Wi-Fi. This is the single highest- value item on the list, because taking money is the one thing you genuinely cannot fake.
A written rule about what you do not do. No comps, no discounts, no refunds while offline — they are the transactions that cannot be reconstructed and the ones most open to dispute.
A reconciliation routine for afterwards. Enter the paper tickets in order, check the count against the duplicates, and reconcile card takings against the terminal's own report rather than the POS. Do it that night, not the next week.
Know how long your queue holds. If your POS caches offline orders, ask what happens when the cache fills or the app is closed. "Do not close the app" is an acceptable answer only if somebody has been told.

The test to run before you sign

Do this during a trial, and do it in this order. It takes fifteen minutes and tells you more than any feature grid.

Ring in a four-item order with a required modifier. Note the tap count.
Fire it to the kitchen. Confirm it appears on the kitchen screen with the modifier and the course.
Pull the internet. Unplug the router or turn off the Wi-Fi on the till.
Ring in another order. Does it work?
Fire it. Does the kitchen screen see it? This is the question that separates the three architectures.
Try to take a card payment. Try to print a receipt.
Reconnect. Does the offline order arrive exactly once? Ring in an order on a second terminal while both are offline, then reconnect both, and check for duplicates or a lost ticket.
Try to close the shift.

Step 7 is the one nobody runs and the one that produces the worst failures. Two tills, both offline, both queueing, is where naive sync produces duplicated or vanished orders — and you will find out on the busiest night rather than on a Tuesday afternoon.

If you build one

A restaurant POS is a realistic build now — we have watched four different coding models produce working ones from a single specification — but cloud architecture is exactly the sort of thing that gets assumed rather than specified, and assumptions here are expensive.

Offline is a branch, not a freebie. It roughly doubles the work of the order path, because you have acquired a local store, a queue, a sync protocol and a conflict rule. Decide explicitly whether you need it. A single-site counter-service cafe on a reliable connection genuinely may not, and saying so in writing is worth more than a half-built offline mode.

If you do want it, the conflict rule is the specification. Two terminals, both offline, both creating orders. Server-assigned identifiers do not exist yet, so the client must generate them, and they must be stable so a retried sync does not create a second order. Write that down; it will not be invented for you.

The kitchen path is the part that gets forgotten. An offline order that the kitchen cannot see is not an offline order.

Decide when stock is deducted. Fire time reflects the kitchen; payment time reflects the accounts. Under an offline queue this stops being philosophical, because the two events may sync in either order.

We saw the general shape of these failures in our own build-off. One system had the tightest financial controls of the four — nothing could be rung up unless the till was open for the day's trading, and past days locked so numbers could not be altered afterwards — but at audit it could only sign people in through its own hosting platform, so it could not be moved anywhere else at all. Another shipped eighteen staff screens, several of which broke in service: the receipt page went blank after a sale, and group bills were double-counted. None of that was a missing feature. It was the deployment and lifecycle behaviour that nobody had specified.

So which should you choose?

Browser-only is right for a single-site venue with a reliable connection where an outage means twenty minutes of paper — a cafe, a counter operation, a small takeaway. It is the cheapest and the simplest, and pretending otherwise to sound robust helps nobody.

Local-first with sync is right for anything where an outage during service is genuinely unacceptable: full-service dine-in, high-volume quick service, anywhere with a queue out the door.

Hybrid caching is the reasonable middle, provided you have run step 5 and step 7 of the test above and know exactly what it does.

Build is right when you are multi-site enough that per-terminal pricing has become a real number, or when your venue shape does not fit what is sold — and when you are willing to specify the offline behaviour rather than hope for it.

The question is not whether a POS is cloud-based. Almost all of them are, in one of three incompatible senses. The question is what your restaurant does at 7:40pm on a Saturday when the connection drops, and whether anyone has ever tested it.

If the question is scope rather than architecture, restaurant management system has the counted feature list from 59 real systems and the eight venue shapes that need different software. Free restaurant POS software covers where the free tiers stop and what a kitchen needs that a retail till does not.

And if you are building, the Restaurant Management planner is the specification we hand our own agents — offline sync gated as an explicit branch, deduction timing decided up front, and acceptance defined as driving the lifecycle rather than screenshotting the screen.