It's 7pm on a Friday and the internet just dropped
Picture the dinner rush at full tilt. Tickets are stacking up, there are walk-ins three deep at the counter, and two delivery drivers are waiting on food. Then the router blinks, the internet cuts out, and the order your cashier was about to send just... freezes. The spinner spins. Every second of that is money and goodwill leaking out the door — and the queue only gets longer.
The frustrating part is that nothing is actually broken. Your tablet works. Your printer works. Your staff know exactly what the customer wants. The only thing missing is a live connection to a server in a data centre hundreds of miles away — and a pure cloud POS has decided it can't take an order without one. This article is about why that happens, what specifically stops working, and how a local-first POS is built to keep ringing sales straight through the outage.
Cloud POS vs. local-first POS: where does the order actually live?
The whole difference comes down to one question: when a cashier taps 'send', where does that order get written first? On a conventional cloud POS, the terminal is essentially a thin window into a remote database. The order is composed in the browser, but it isn't real until the server writes it down and confirms. No connection, no confirmation, no order — and no way to fire it to the kitchen.
A local-first POS flips that around. The terminal keeps a working copy of your menu, prices, tax rules and modifiers on the device itself, and every order is written to local storage on that device first, then synced up to head office in the background. Losing the internet doesn't stop the sale; it just delays the sync. The order is already real and saved the instant your cashier taps 'send'. Connectivity becomes a background convenience rather than a hard dependency for taking money.
What actually stops working without offline mode
'The POS is down' is vague. Here is what concretely breaks on a connection-dependent terminal the moment the link drops. Order entry stalls first — new tickets won't commit, so the line backs up at the counter while food waits. Check splitting and modifier pricing often fail next, because those calculations round-trip to the server. Kitchen tickets stop firing, so even the orders you did manage to take never reach the cooks. And card payments won't authorize, because the terminal can't reach the processor to approve the tap. Any one of these mid-rush is painful; together they stop the store.
The knock-on effects outlast the outage itself. Orders scribbled on paper during the freeze have to be re-keyed afterward, which is exactly when totals get mistyped, comps get forgotten, and your end-of-night numbers stop matching the till. The outage might last four minutes; the reconciliation mess lasts the rest of the shift. This is why offline capability is less about avoiding a rare disaster and more about protecting the quiet accuracy of every normal service.
Store-and-forward, and the honest truth about card payments offline
Order entry is the easy half to keep running offline — it's just data your device already has. Card payments are the harder, more honest half, because authorizing a card genuinely requires reaching the payment processor. This is where 'store-and-forward' comes in: the terminal securely stores the transaction locally, then forwards it to the processor once connectivity returns, instead of failing outright at the moment of the tap.
Be clear-eyed about the trade-off, because a lot of marketing glosses over it. Store-and-forward for cards means you accept a payment before it has actually been approved, so a card that would have declined only surfaces later — you are taking on that risk in exchange for not turning paying customers away. Whether it is available at all depends on your payment processor, not just your POS software. The one tender that always works offline is cash: it needs no authorization, and the drawer can pop locally. A well-built local-first POS lets you keep selling on cash without hesitation, queues the full transaction record whichever way it was paid, and reconciles everything automatically on reconnect so your books still balance.
Where Syntraq 360 is today — the honest answer
We would rather tell you this now than have you find out on a Friday: Syntraq 360 runs in the browser today, and it does not keep selling through an internet outage. If the connection drops mid-rush, the terminal cannot take a new order. Offline-capable, local-first terminals are the next thing we are building, and they are not shipping yet. If surviving an outage is the deciding factor for your restaurant right now, buy the system that can prove it today.
What is built, and built properly, is the hardware and money layer that an offline terminal would sit on top of. Syntraq speaks standard ESC/POS, so the same Epson, Star or Munbyn printer that fires kitchen chits also prints customer receipts. The cash-drawer and pole-display byte sequences are written and unit-tested against the same compiler, but be clear about what that means: nothing in the product calls them yet, so there is no button today that opens a drawer. A printer is claimed before it is dialled, so a ticket cannot print twice, and a failed print returns to the queue rather than vanishing. Every order carries a unique short code that the system de-duplicates on, so a replayed or double-tapped ticket never creates two orders — the exact mechanism an offline queue needs when it flushes.
That ordering matters. Offline mode is easy to demo and hard to get right, because the difficult part is not storing an order on a device — it is making sure that when a hundred queued tickets flush, none of them duplicates, none is lost, the totals still reconcile, and the tax on each is the tax that applied when it was rung. We built that half first. The local queue is the part still to come.
The one question to ask every vendor
Offline resilience is not a feature you notice every day — it is the thing you are quietly grateful for on the one Friday a month your internet has a bad night. If you are comparing POS systems, put the same direct question to every vendor, us included: when the Wi-Fi drops, can I still take an order, fire it to the kitchen, and open the cash drawer? Then ask them to show you, on their hardware, by unplugging it. For a lot of cloud-only POS products the honest answer is no, and you will only get it by making them demonstrate rather than describe.
Ask the follow-up too, because it is where the real cost hides: what happens to card payments while you are offline, and who carries the loss if a stored transaction is declined when it finally reaches the processor? A vendor who answers that one clearly is telling you the truth about the rest.
Syntraq 360 is an independent, early-stage restaurant platform. We are not going to claim an offline mode we have not shipped. If you want to see where the platform genuinely is today — the ordering, the kitchen display, the ESC/POS printing setup, the multi-store menu and pricing control — reach out through the contact page and we will show you exactly that, including the limits. The cash drawer is one of those limits: the sequences are written, and nothing in the product calls them yet.