Insights · 5 min read
A POS demo looks fine at 3pm on a Tuesday. The test is Friday at 7pm with forty open tickets. The real build is self-service, the kitchen, and offline mode.
By GGP Editorial
Every restaurant POS demo looks good at 3pm on a Tuesday. The terminal takes an order, prints a receipt, maybe shows a little sales chart. Then Friday night arrives, forty tickets are open at once, the internet drops for ninety seconds, and the system that looked fine now decides whether the whole floor grinds to a halt.
We built a self-service ordering plus POS system for a restaurant chain, and the interesting work was never the part you see in the demo.
Self-service is the piece restaurants ask for most now. A kiosk by the counter, a QR code on the table, an order that lands in the same queue as the ones from the cashier. It sounds like a form, and it is, right up until you have to handle modifiers and combos.
A customer ordering "no onion, extra sauce, upsized drink" is three nested decisions the menu has to model. Get that structure wrong and the kitchen receives tickets that read like riddles. The menu is a data model first and a screen second. Most projects fail because someone designed it the other way around.
There is also an operational angle owners don't expect. When a price changes or an item sells out, the change has to reach every kiosk, every QR menu, and every terminal in minutes, not after someone remembers to update a spreadsheet. A menu that lives in one place and syncs everywhere is what makes self-service worth it in the first place.
The kitchen does not care about your brand colors. It cares about one thing: does this ticket show the right items, in the right order, with the right modifiers, at the right time. A kitchen display system has to keep tickets moving through states (new, in progress, ready) and bump them automatically when a station is slammed.
The small details matter here. Printer fallback when the display dies. Timers so one table's food doesn't sit under the heat lamp. A "fire" action so mains don't start cooking before the appetizers leave the pass. Allergen flags that follow an item through every modification. These sound trivial until a Saturday night proves otherwise, and then they become the difference between a clean service and a line of angry customers at the counter.
Payment is where the pressure peaks. Card, QR, and cash all at once, tips, split bills, refunds. And every one of those has to keep working when the internet drops, because it will drop.
| Mode | What keeps working | What waits |
|---|---|---|
| Online | Live card auth, cloud sync, reporting | Nothing, when the connection holds |
| Offline | Orders, kitchen tickets, cash and stored-card | Card auth, remote reporting |
A POS that dies without Wi-Fi is a liability, not a feature. We build offline fallback in from the start: the terminal keeps taking orders and queuing card authorizations, then syncs when the connection returns. Restaurants in areas with patchy internet notice this more than any other feature.
Split bills and tips are the kind of requirement that looks like one line on a spec and turns into a week of edge cases. Four people, two cards, one person pays the tip, someone else wants their share on a different card. If the flow makes the cashier do mental math at the till, the line backs up and everyone feels it.
Behind the counter there is a quieter set of jobs: menu versioning across stores, inventory that depletes as items sell, and end-of-day reports the owner actually reads. Multi-store operations need a single view, which is why the back office lives as a web app while the terminals run lean. Staff log in with roles, so a cashier can refund a small amount but can't touch the week's sales figures, and managers can pull a shift report without calling support.
For this kind of build we tend to reach for Vue on the front end with Node or Go behind it, backed by MySQL and Redis, with Nginx in front. It is a stack we have used across financial systems, property management, and payment work, so it holds up under load.
GlobeSoft is a China-based team that ships for clients in Brazil, South Africa, Singapore, and the US. We run a daily overlap window, keep a dedicated group chat, and work in English or Portuguese. If it is legal, we will build it, restaurant tech or anything else.
If your POS is fine on quiet Tuesdays and scary on Fridays, tell us what is breaking.
Tell us what you are building and where you are today. We typically reply within 24 hours.
