goserve

A café in Kathmandu runs on a paper tab, a calculator and somebody’s memory of who ordered the second chai. The software that would fix it is priced per terminal in dollars, assumes card rails that aren’t there, and has no idea what 13% VAT on a paisa-denominated bill looks like.

The multi-tenant part is where this kind of thing usually goes wrong. Every café on one deployment is the only way the economics work — and it’s also one missing WHERE clause away from showing one owner another’s takings.

Tenant isolation is enforced by Postgres row-level security, not by application code. The runtime connects as a role created NOBYPASSRLS, so a query that forgets its tenant filter returns nothing rather than everything — the boundary holds even when the code above it is wrong, which is the only version of that boundary worth having.

The service flow is the real one: a tab opens on a table or as a named walk-in, items are added and sent to a kitchen screen, tickets advance from cooking to ready to served, and only then does the tab offer to settle. The kitchen view updates over WebSockets, because a second screen that needs refreshing is a second screen nobody looks at.

Money is integer paisa end to end, with 13% VAT and cash plus eSewa and Khalti QR reconciled by hand — the honest version of a payment integration in a market where the rails are QR codes and a bank statement.

It’s a Turborepo of four apps — API, web, landing, mobile — over six shared packages, including design tokens, an RBAC model, receipt formatting, and API types generated from the Go service so the client cannot drift from the server it calls.