Insights · 5 min read
What a restaurant POS really needs to do, how self-ordering changes the math, and real costs for a custom system, from a team that has built one.
By GGP Editorial
A restaurant POS system is one of the few software projects where the buyer and the user are rarely the same person. The owner pays for it, the staff fights it, and the customer only notices it when it is slow. That gap explains most of the bad POS software on the market.
We built a self-ordering and POS system for a restaurant group, and the feature that surprised everyone was not the ordering flow. It was the payment reconciliation at close of day.
The register is the easy part. A system worth paying for has to handle several jobs at the same time, and they rarely come from the same vendor.
| Layer | What it covers | Why it matters |
|---|---|---|
| Ordering | Dine-in, takeaway, kiosk, QR ordering | Tables turn faster |
| Kitchen flow | Ticket routing, prep times, modifiers | Fewer mistakes, less waste |
| Payments | Cards, wallets, split bills, tips | Reconciliation and cash-up |
| Back office | Inventory, shifts, menu pricing | The part owners actually read |
Most vendors stop at the ordering layer. The back office is where the real value sits, because that is where a restaurant either makes money or quietly leaks it.
A self-ordering kiosk or a QR menu does more than cut a server's steps. It raises the average ticket, because the menu sells extras the way a hurried server never will. Modifiers like 'add guacamole' or 'upsize' convert far better when a customer taps them than when a staff member has to ask.
It also removes the most expensive mistake in a restaurant: a wrong order. When the customer enters their own order, the kitchen receives exactly what was tapped, and the argument over who misheard disappears.
The catch is integration. Self-ordering has to feed the same kitchen display, the same inventory, and the same payment rails as the counter. Run it as a separate app with a separate database and you have two systems to reconcile, which is worse than one.
Ordering is simple. Paying is not. A restaurant has to handle cards, wallets, split bills, tips, refunds, and the daily cash-up, and every one of those has an edge case. Split a bill across four cards and one fails: is the order still paid or not? A customer taps a wallet and the terminal times out: did the payment settle or not?
The way to avoid most of this pain is to integrate a payment provider early and design the reconciliation from day one, not after launch. For restaurants that take QR or mini-program payments, that integration matters even more, because the payment lives inside your app rather than at a terminal.
Reconciliation is what a good POS does well and a bad one hides. At close of day, the totals from the terminal, the kitchen, and the bank should match to the cent. If they do not, someone spends an hour finding the gap. Build that check into the system and the owner stops dreading the end of the night.
A custom POS for a single location runs $15,000 to $40,000. A multi-location group with self-ordering, loyalty, and delivery integrations lands between $50,000 and $120,000. The spread comes down to three things: how many payment methods you support, whether you need offline mode, and how much of the menu and inventory logic is custom.
Offline mode is the one clients forget to ask for. When the internet drops on a Friday night, a POS that cannot keep taking orders is a disaster, and it is worth the extra build cost to avoid.
Buy a POS if your menu is standard and your needs stop at taking orders and cards. Build when you have a specific flow, like table-side ordering, a loyalty program tied to a mini-program, or multi-brand reporting no off-the-shelf vendor supports.
That last point is the real decision. A Chinese restaurant chain expanding into Southeast Asia does not want three different POS vendors per country. They want one system with one dashboard, and that is a build.
Delivery is another reason to build. If your kitchen takes orders from two or three aggregators, each one prints to its own tablet and someone has to re-key every order into your POS. A built system can pull aggregator orders into one kitchen display automatically. That alone saves a manager's evening on busy nights.
If you build, pick a team that has done it before. A POS touches hardware, payments, and kitchen operations at once, and a team learning on the job will cost you more than the difference in rates. We run a China-based team that ships for clients in Brazil, South Africa, Singapore, and the US, with overlapping hours and a dedicated group in English and Portuguese, so the timezone gap never blocks a launch.
Tell us what you are building and where you are today. We typically reply within 24 hours.
