2026
Rizzoto
Offline-first restaurant POS · built by Vikrant Kumar
A restaurant POS that keeps billing, KOTs and the kitchen screen running even when the internet goes down.
Tables, grouped by area
The problem
Small restaurants and cafes in India bill on cloud POS systems that stop the moment the Wi-Fi drops, right in the middle of a rush. I wanted one system an owner can sign up for in minutes and run the whole outlet from: GST billing, KOTs to the kitchen, menu, tables, stock, staff logins and reports. And it had to keep working when the internet doesn't.
Decisions and why
One bill calculator shared by server and client
GST splits, discounts, service charge and round-off live in a shared TypeScript package used by the API, the POS preview and the offline engine. The total a customer sees offline is exactly what the server records later. Amounts are worked out in paise, so floating point never puts a bill off by a rupee.
Device-numbered bills for offline work
Invoice numbers have to be gap-free per outlet and financial year. A till without internet can't ask the server for the next number, so offline bills carry the till's code (IND01/26-27/D1-00004). They can never clash with server numbers, and the sequence stays legal once it syncs.
A local hub on the counter PC instead of offline mode in every tablet
Browser-only offline works for one till, but waiters' tablets and the kitchen screen still need to see each other's orders. The Windows app runs a small hub on the shop's Wi-Fi. Online it just proxies to the cloud; offline it serves orders, KOTs, bills and the kitchen screen itself, then replays everything to the cloud in order.
Server-sent events for live screens
Tills and the kitchen only need to hear 'something changed, refetch'. SSE gave live updates over plain HTTP with no extra infrastructure, and the hub can fake the same stream locally when offline.
Auto-updates from GitHub Releases
Asking a cafe owner to reinstall an .exe for every fix doesn't work. The desktop app downloads updates in the background (usually under 1 MB thanks to differential downloads) and installs on the next start, so it never restarts mid-service.
The hardest part
Keeping data correct across an outage. While offline, the hub numbers orders and KOTs itself and queues every change with the session of the person who made it. When the internet returns, it replays the queue in order through the normal API. Server-assigned KOT ids are mapped back onto the local ones, and anything the server rejects is parked as 'not synced' instead of blocking every other order. I tested it end to end with Playwright: cut the connection, have a waiter's tablet send a KOT, see it on the kitchen screen, settle the bill at the counter, reconnect, and check that the cloud has the exact paid order and invoice.