Off-the-shelf POS software breaks in the same place in most cafés: the system records the sale but does not remember the customer. For Sisa Atelier, till, kitchen, reporting and loyalty were built as one system over one dataset.
A café POS system developed and deployed with Docker. It covers table and till flow, audited void/undo operations and sales reporting. On top of it sits a loyalty engine managing stamps, points, coupons and campaign rules, and the QR menu — previously a WordPress page — was moved inside the same system. The café's WordPress marketing site also received a substantial speed overhaul.
Most POS products on the market are technically fine. The problem usually appears here: the system records the sale, prints the end-of-day report, and stops. Who came how often, which customer bought which product, who should receive which campaign — all of that stays outside the system. It is a café's most valuable data and it is usually never collected.
The second problem is lock-in: if the off-the-shelf product has a loyalty feature, that feature works one fixed way. If "buy five coffees, get the sixth free" does not fit the business, it cannot be changed.
For those two reasons the system was built in-house, and loyalty was designed as a natural part of the system rather than a bolted-on module.
The only measure of a POS interface is speed. During a rush, the person at the till does not read the screen — they work from reflex. So:
Deployment uses Docker. The practical benefit is updates: a new version ships to the server without manual installation at the till, so no device is left running an old build.
The most sensitive function in a POS system is not adding a sale but removing one. A mistyped item has to be correctable — yet a record that can vanish without trace is the most common route to till shrinkage.
So voids and undos were treated as their own capability: an operation can be reversed, but it leaves a trail. What was voided, when, and by whom stays on the record, and reporting was built to surface those entries.
Technically a small decision; operationally the whole basis of trust. A system is reliable because it remembers what it deleted.
Loyalty was written as an engine with definable rules rather than one fixed scheme. Four mechanisms work together:
The engine's real value is that the rule is not baked into the code. When the business wants "double stamps on filter coffee on Tuesdays", no software update is needed — the rule is defined.
Note: the engine is live and running; which campaigns to define is the business's commercial decision. The system is waiting on that decision, not blocking it.
The café's QR menu originally lived on a subpage of the WordPress site. Practical on day one, problematic long term: a price change meant updating in two places, and WordPress's weight became a wait for a customer opening the menu at the table.
So the QR menu was moved inside the POS system — the menu now reads from the same product data as the till. Update a price at the till and the menu at the table is current.
A separate speed pass was run on the café's WordPress site. The biggest item was imagery: the media folder had grown unmanageably large and had never been converted to a modern format. Converting to WebP dropped the folder by an order of magnitude — from about 147 MB to roughly 10 MB.
Beyond that, server-side caching and compression settings were tuned, unnecessary theme demo content was cleaned out, and admin-side slowness was addressed separately through the PHP version and the caching plugin.
Sisa Atelier now runs its till, its menu and its loyalty programme from one system. Voided sales leave a trail, reports surface those trails, and the QR menu is fed by the same data as the till.
The transferable lesson: the differentiator in a café POS is not speed or interface but whether the system remembers the customer. Every product records sales; the one that knows how often a customer returns — and can build campaigns on it — sustains the same revenue with fewer new customers.
For a single-site business operating conventionally, an off-the-shelf product is usually enough. Custom becomes worthwhile when your loyalty scheme, campaign logic or reporting needs do not fit the shape the product allows. The deciding question: how valuable is it that your system remembers the customer?
They work more for bringing existing customers back than for acquiring new ones — and that is where café profitability actually sits. The condition is that the rule fits the business: fixed in off-the-shelf systems, definable in your own engine, so it can be tuned by trying.
Because the most common route to till shrinkage is a recorded sale being deleted without trace. The right setup does not forbid voids — mistakes happen everywhere — but records who voided what, when, and surfaces it in reports. That is where a system's reliability begins.
A single source of price. Kept separate, a price updated at the till stays stale on the menu and the customer sees a different figure at the table. Fed from the same data, that inconsistency is structurally impossible — and there is no second panel to log into.