The hard part of a POS system is not recording orders. The hard part is staying readable during a rush, remembering the sale you deleted, surviving a dropped connection and guaranteeing that price comes from one place.
Five decisions determine the outcome of a restaurant POS: (1) voids and undos must not be forbidden but must leave a trail; (2) the till interface must be touch-first and low-tap, usable by reflex; (3) the kitchen screen must be a status display showing waiting time by colour, not an order list; (4) menu price must come from one source, QR menu included; (5) loyalty data must be a natural part of the sales record, not a bolted-on module. These decisions matter more than the language or framework.
Most developers writing a POS start with the data model: table, order, product, payment. That model works within a week and the system looks finished.
The real problems start afterwards, and none of them are about the data model:
Not one of those is solved by a better database schema. All of them are product decisions.
The most sensitive function in a POS is not adding a sale but removing one.
Both extremes are wrong. Forbid voids and the system becomes unusable — mistakes happen in every service and must be correctable. Allow free voids and you have opened the easiest route to till shrinkage: enter the item, take the money, delete the record.
The correct setup is in the middle: voids are allowed but leave a trail.
Technically a small decision — mark rather than delete. Operationally, the entire reliability of the system comes from it.
The only measure of a till interface is speed, and speed comes from tap count, not visual minimalism.
A web-based POS has an advantage here: the same application can run as different views on the till, a tablet and the kitchen screen. No per-device install, no version drift.
The most common mistake is giving the kitchen the admin order list. That list was designed for an e-commerce operation: filters, search, pagination, bulk actions.
The person in the kitchen does not read lists. They glance at the screen from a metre and a half away with their hands full. The screen has to tell them one thing: what should I do now?
In restaurants, price appears in at least three places: the till, the printed or QR menu, and the online ordering site if there is one. Held in separate systems, they inevitably drift — a price rises, one is updated, the other forgotten.
The result is an argument with the customer, and the business loses that argument every time.
The correct setup: price has one source and every other surface reads from it. The QR menu should be fed by the POS product data — not a separate menu site but another view of the same data. Update the price at the till and the menu at the table is current.
In a restaurant, the connection will drop. That is not a probability but a matter of time. If the system is unprepared, service stops and the business falls back to paper — and that service's data is lost permanently.
For a web-based POS, resilience is tiered and each tier costs more:
Which tier is required depends on the business — and it is a budget decision, not a technical necessity. But the decision must be made deliberately. The worst case is the setup where nobody asked, and the answer is discovered during the first outage.
In most systems the loyalty programme is a module added afterwards, and that is why it works badly: the sales record and the customer record live in different places, matching them depends on the cashier's initiative, and the data is collected half-complete.
Yet all loyalty needs is recording who the sale was made to. That is a decision to make at the start.
Once it is made, everything else follows: stamps, points, coupons and campaign rules bound to time, product or customer group.
The critical design decision is that the rule must not be baked into the code. "Double stamps on filter coffee on Tuesdays" should not require a software update; it should be definable. Otherwise the business stops experimenting and the system carries a dead feature.
What distinguishes a POS is not the technology choice but five decisions: voids leave a trail, the till works in few taps, the kitchen screen shows status, price comes from one source, and the sale knows who it was made to.
Get those right and an ordinary technology stack is enough. Get them wrong and even the most modern stack gets abandoned in the field.
An example of this architecture in practice: the Sisa Atelier POS and loyalty system.
For a single-site business operating conventionally, an off-the-shelf product is usually cheaper and sufficient. Custom becomes worthwhile when loyalty design, campaign logic or reporting needs do not fit the shape the product allows. The deciding question: how valuable is it that the system remembers the customer and that you set the rules?
Yes, provided the screen is readable from a distance. Kitchen staff look from about a metre and a half away; a small-type order list is useless. Being able to see waiting time and the lateness colour from that distance matters more than screen size.
It depends which resilience tier the setup is built to. At the simplest tier the system warns and loses no data but cannot take orders. At the middle tier open orders are held on the device and sync when the connection returns. It is a budget decision — what matters is making it deliberately at build time.
They work more for bringing existing customers back than acquiring new ones — which is where café profitability largely sits. The condition is that the rule fits the business and can be tuned by trying. In a system where the rule is fixed, the loyalty feature falls out of use quickly.