Tablelane
QR ordering and live operations for independent specialty cafés. The goal: technology that stays out of the way of hospitality.
- Product design, UX, front-end, bilingual build
- 2026
- Next.js, TypeScript, Tailwind, Playwright
Context
Ordering platforms are usually built for chains. A single specialty café with twenty to sixty seats and both counter and table service needs something calmer: guests order from the table, the bar sees one readable queue, and the team keeps doing the hospitality.
What had to be true
One end-to-end proof: a guest order appears in the staff queue, staff move it through its states, and marking an item as sold out reaches the guest menu immediately.
Everything else was scoped out on purpose: payments, reservations, inventory accounting, payroll and delivery. Every button either works, explains itself or is clearly labelled as a demo.
Two languages, one state
The demo state is stored once; Persian is a full display layer on top of it, not a translation file. Persian gets Persian digits, the Solar Hijri calendar, mirrored layouts, and order numbers isolated so they never reorder a sentence. A small rule that mattered: Persian never uses the middle dot, because in Persian type it looks like a zero.
Decisions that shaped it
Deterministic demo state
A seeded, persistent state lets anyone walk the full guest-to-bar flow in a meeting without a backend.
Tested like a product
Browser tests cover the ordering flow in both languages at desktop and phone sizes.
Screens
Where it stands
- Released as v1.0.0: marketing site, guest QR ordering and staff app, in English and Persian.
- A public domain for the live demo.
What I learned
Right-to-left is a design decision, not a CSS property. The Persian version only felt native once every separator, number and date had been designed for it.