Bhuk — Ordering, Kitchen & POS

The build

A mid-range restaurant in this country usually runs three unrelated systems that each think they own the truth: an ordering page or Facebook inbox out front, an iPad POS or paper docket at the counter, and a kitchen that gets orders by a shout. Bhuk is the opposite architecture: one order state machine with four faces — the customer's menu with live prep time, the kitchen's ticket board of status and elapsed minutes, the cashier's tile POS that reconciles every bill in front of the guest, and a dispatch view that hands riders the same states, batched. We earned the design standing in actual supper-club service nights, where a wrong number is a wrong plate and you learn fast. It is offered the same way every blueprint is: your venue, your accounts, your data exportable, one flat licence.

What we handled

• One state machine, four surfaces: every screen shows the same truth because it is literally the same object
• Menu with live prep — average kitchen time drives promised ETA, so “30–40 min” stops being fiction
• Ticket board built for a line cook: status word, elapsed timer, colour = urgency, zero reading required
• POS math shown in the open — subtotal, service, VAT, splits — the receipt and the screen never disagree
• Batched dispatch with COD flags: routes grouped by kitchen-ready time, not by random arrival order
• Menu import from whatever exists — photos, prices, variants — and outlets get their own rules inside one system

Three systems, zero shared truth

The anatomy of a bad Friday at a mid-range Dhaka restaurant is consistent everywhere: the ordering page accepts an order at 8:02, the cashier writes it on a docket at 8:04, the kitchen hears “table five plus a delivery” at 8:06, and the rider is messaged to come at 8:20 to find the food ready since 8:12 and the napkins not packed since never. Nobody is careless; the systems simply do not share a state, so the staff became the message bus, and message buses have peak hours.

Bhuk inverts the shape: one order object, four views. The customer's menu, the kitchen's board, the cashier's till and the dispatch list are projections of the same record — a tap anywhere moves everywhere within a blink. It is a decade-old idea in rich markets and treated as exotic here, and the exotic part is not the tech; it is refusing to ship the four faces until they agree. Every design decision in Bhuk starts from that refusal.

The menu is a kitchen promise

Ordering UI is commodity; the live prep time is the product. Bhuk watches the actual kitchen — average minutes per station, ticket load, current queue depth — and the menu states a promise it can keep: “avg 24 min · Live”, with the ETA recomputed when the biryani pot is three deep. Sellers hate this feature until their first Friday; refunds for blown windows drop because the window stopped being fiction.

Menu structure maps to how Bangladeshi kitchens actually cook: variants (spice level, rice swap), modifiers that decrement real stock, availability per daypart, and sold-out states the kitchen can flip from a phone because the line cook, not the marketing calendar, knows the Daab Chingri ended at 9.

A board a line cook reads at a glance

The kitchen display is the most opinionated surface here: no item paragraphs, no logos, one ticket per card — number, count, status word, elapsed timer — colour as the only other language (fire, cooking, ready, late). Everything else is a settings page the manager visits once a week. We watched our own kitchen ignore two “richer” prototypes before this one stuck, and the lesson went into the product: in the pass, reading is friction, and glance is truth.

Because tickets are state objects, not text notes, the same board drives the rider batching, the customer's “on the fire” notification, and the timing stats the owner sees Monday. The chef's phone carries the identical list — Mark served is one green thumbprint — because a kitchen that can walk can also keep answering questions from the pass.

The till shows its arithmetic

Bhuk's POS is tap tiles and an open ledger: items, subtotal, service percentage, VAT, total, splits — each line visible while it computes, on the owner screen and the guest phone together. Our own renders do this on purpose: ৳280 + ৳350 + ৳60 + ৳80 = ৳770, plus 5% service ৳39, plus VAT ৳77 = ৳886, split four ways ৳221.50 each. If a billing system cannot tolerate being read, it is not ready to be trusted.

Tenders are local and honest — cash drawer, bKash, card via SSLCommerz — and closing a bill writes the same record the kitchen, dispatch and the daily revenue sheet read, including the delivery orders whose COD is flagged into the rider's run and back into the settlement, so the till, the bag and the report cannot tell three different stories about the same taka.

Runners batched by the kitchen, not by luck

Dispatch in most venues is a group chat with a map screenshot. Here it is a queue grouped by ready-time: when tickets hit READY in a cluster, the batch exists — rider list with states, distance and COD flags per stop, one Start run on the phone. The system never invents an ETA it cannot defend; if the kitchen queue deepens, batches merge and customers see the honest delay because every face reads the same object.

Restaurants that run their own riders get the full board; those on the open courier fleets get a webhook out and a status back — Bhuk does not pretend to own the street. And the owner's Monday view closes the loop the Friday rush opens: on-time percentage, prep drift, COD float, refund reasons — numbers a system that shared its truth all week can afford to show.