Tumynos

Overview

Tumynos needed more than a menu online. We built a full operations platform: a customer ordering app, a kitchen display system, a driver app, and an admin layer with analytics — all realtime, all one codebase. The production build compiles to 130 pages with zero errors. This is what "digital systems studio" means in a kitchen: software that runs the business, not a brochure that describes it. evidence: observed

Business context

Independent restaurants rent their own customers back from aggregator platforms, order by order, at commission rates that eat the margin on every pizza. Owning the ordering channel converts a permanent tax into a one-time build.

Challenge

Restaurant software fails in the gap between apps: the order that prints but never cooks, the driver who leaves before the box closes. The challenge was never any single screen — it was making four roles (customer, kitchen, driver, admin) share one truthful, realtime state.

Strategy

Design the order's journey first, screens second. Every order moves through explicit states — placed, confirmed, cooking, ready, out, delivered — and every app is just a lens on that single state machine. When the state model is honest, the UIs almost design themselves.

The client didn't buy pages. They bought an operating capability.

Decision making

Server-Sent Events over heavier realtime infrastructure. Kitchen and driver views need server-to-client updates, not chat. SSE delivers that with a fraction of the operational complexity of socket infrastructure — the boring choice that a restaurant can run for years unattended.

Kitchen display as a first-class product. Most ordering systems treat the kitchen as a printer. We designed the KDS for the actual environment: glanceable at distance, tap targets for floury fingers, state changes visible across the room.

One codebase, four apps. Roles share components, types, and the state machine. Divergence between apps is where operational bugs breed; a monorepo of one is the cure.

Development

Next.js 15 with TypeScript end to end. The discipline that mattered most was typing the order state machine exhaustively — the compiler now refuses impossible order states, which in a restaurant means the software cannot represent a lie about dinner.

Performance

The customer app is optimized for the mid-range phone on restaurant Wi-Fi: route-level code splitting, minimal client JavaScript on the menu path, images sized to the component. The verified production build — 130 pages, zero errors — is the project's quality floor, recorded in the QA file.

Accessibility

AA contrast throughout, full keyboard operability in the admin, and status conveyed in words as well as color across the KDS — a colorblind cook must read the board as fast as anyone.

Reflection

Tumynos is the clearest expression so far of the studio's thesis in product form: the client didn't buy pages, they bought an operating capability. It also taught us that back-of-house software earns its keep on the worst night of the week — every design review since asks "what does this screen look like during the Friday rush?"

Future improvements

Loyalty and re-order flows are the natural compound: the ordering channel the restaurant now owns becomes the marketing channel too.