KAFE KUFE
Restaurant OS That Increases Café Profit by 20%
Profit Impact
WebSocket Latency
Module Architecture
Role Tiers
Restaurant operators face a fragmentation problem. A typical mid-size chain juggles a POS terminal that doesn't talk to the kitchen, spreadsheets for inventory with no purchase order tracking, a third-party loyalty app with no integration to the bill, WhatsApp groups for staff task coordination, and manual GST reconciliation at month-end. Each tool works in isolation. Data doesn't flow. Errors multiply at handoff points.
We built a single platform that owns the full operational loop — from a guest scanning a QR code to a manager seeing real-time P&L. The system uses a role-gated, module-entitlement architecture that lets operators pay for only what they use, with a WebSocket layer that broadcasts order status changes to all connected clients within milliseconds. The fail-open entitlement design reflects domain knowledge: for a restaurant mid-service, a lockout is catastrophically worse than brief unauthorized access.
Under the Hood
Module Entitlement Engine
Runtime module resolution with three layers: plan-level defaults, per-restaurant overrides, and client-side cache with a 15-minute TTL. Fail-open design grants access if the entitlement check itself fails — preventing lockouts during service.
WebSocket Real-Time Layer
Orders flow through a WebSocket layer that broadcasts status changes to kitchen screens, waiter devices, and manager dashboards simultaneously. Redux ordersSlice holds canonical client-side state with WebSocket events dispatched as actions.
Three Distinct Visual Systems
POS theme (dark, high-contrast for kitchen lighting), inventory theme (data-dense for desktop), and customer theme (warm, food-photography-first for mobile). Each with its own Tailwind config tokens.
Order State Machine
Orders move through received → preparing → ready → served → completed (or cancelled). Each transition is permission-gated — staff can mark "preparing", only managers can cancel.
- +Smart POS with one-tap ordering, table-based workflow, and multi-payment modes (UPI, Card, Cash)
- +Order state machine: received → preparing → ready → served → completed, permission-gated per role
- +Touch-optimised kitchen display updating in real time via WebSocket — no polling, no reload
- +GST billing with PDF invoices, bulk ZIP export for accountants, and Razorpay online payment
- +QR table ordering — unique per-table codes, guests order directly, kitchen sees "Table 4 — Pasta" instantly
- +Customer PWA: no download required, full menu with images, cart, offline support, loyalty login
- +Inventory chain: raw materials → semi-finished goods → finished dishes, with waste tracking and reorder alerts
- +Points-based loyalty engine with Bronze→Platinum tiers, milestone rewards, and campaign targeting
- +FSSAI compliance checklists with photo verification, replacing physical logbooks
- +Real-time analytics: order counts, revenue by hour, average order value, payment mode split — no separate BI tool
- +Staff management: unlimited accounts, 5 role tiers, Firebase JWT auth, activity tracking
- +Multi-outlet support: manage multiple locations from one login with separate analytics per site
Why We Did
What We Did
Every architectural decision has a reason. Here are the ones worth explaining.
Why fail-open module gating?
Most SaaS platforms fail-closed on entitlement checks — if the permission service is down, users get locked out. For a restaurant mid-service, a lockout is catastrophically worse than brief unauthorized access. The decision reflects domain knowledge, not just engineering preference.
Why Redux for orders but Context for everything else?
Orders have complex, cross-component state requirements — a status change on a kitchen screen must reflect instantly on billing and the manager dashboard. Redux with WebSocket-dispatched actions handles this reliably. Everything else lives in React Context, keeping the Redux surface area minimal.
Why Pages Router for staff app but App Router for customer app?
The staff POS was built before App Router was production-stable for complex real-time UIs. Migrating mid-product is high-risk with low reward. The customer app, being newer and simpler, benefits from App Router streaming and server component patterns.
Something Like This
In Mind?
Tell us what you're building. We'll tell you how we'd do it.