Customers scan one QR and order from any participating stall — food and drinks, same sitting. Each stall's orders arrive on its own phone or tablet, and each stall keeps its own menu, prices and bank account.
Tenants start receiving orders without replacing their existing POS — and can add StallPOS cashier features later on the same menu and merchant setup.
A concept — nothing is running at a coffee shop yet, and we say so. The ordering engine underneath runs at our own stall every day. The demo is fully simulated.


In many coffee shops the operator runs the drinks stall — the one serving every table anyway. When other stallholders see it working at a real rush hour, they ask to join.
All participating stalls in one bilingual menu — food and drinks in the same sitting, one order per stall.
SIMULATED
On a device the stall may already own, set up once with one-time secure device pairing — staff don't log in day-to-day. Chime + spoken alert; instructions like "less rice 少饭" in plain words.
SIMULATED
Placed, accepted, ready — "collect at the drinks stall", not wandering and asking. Order status and payment status are tracked separately, honestly.
SIMULATED
We photograph the menu once — the same menu serves QR ordering and, later, the optional cashier. The stall's own phone is paired, and a test order confirms the ring before any real customer.
SIMULATEDPayments: every PayNow goes directly into each stall's own bank account — we never hold money and take no cut. One QR is not one checkout: each stall is paid separately. A soundbox says money arrived — not which order — so the stall confirms each payment with one tap.
Takes every QR order and PayNow at our own 4 MEE noodle stall daily since Sep 2026. A second trilingual menu (Thai kitchen, pre-opening) runs the same engine.
One shared table QR routing orders to multiple independent stalls — a working concept you can click through in the interactive demo.
Not included today, honestly: a single combined checkout or split billing, card payments, delivery-platform sync, runner dispatch, printed chits, automatic multi-merchant bank confirmation.
One coffee shop. One willing stall to start — drinks recommended — up to two more if they ask. We install the table QRs, build the menus bilingually, pair the stalls' own devices, stand with you on day one, and support on WhatsApp throughout. At the end, you and the stallholders decide on real evidence: scans, orders, response times, and whether lunch ran smoother.
What we need: your go-ahead, one willing stall, table space for stickers, Wi-Fi or mobile data at the stalls. Pricing is discussed, not published — the first conversation sizes it honestly for your coffee shop.
Both models exist; early installations help shape this with you. The receiver is included under the platform — nothing is forced on a tenant.
On their own phone or tablet, set up once with one-time secure device pairing — staff never log in day-to-day. A chime and spoken alert announce each order.
Direct to each stall's own bank; each stall settles separately (no combined bill). A soundbox can't say which order a payment belongs to — the stall confirms with one tap.
QR counts, statuses and table activity — not the stalls' sales. Financial visibility only ever happens with the stall's explicit permission.
Yes and yes. The optional StallPOS cashier uses the same menu and merchant setup — try the simulated preview in the demo; it is a proposed feature, not a deployed one.
Honestly: no. The engine runs at our own stall daily; the multi-stall layer is what we'd build first — that's why everything here links to a labelled simulation.
StallPOS by Madam Chin Kitchen Pte Ltd · UEN 202637886D · 5058 Coffee Shop, Singapore — this page describes a concept; every coffee-shop screen shown is a labelled simulation.