Lede

There is a small Chinese takeaway in Weymouth where every order — phone, website, Deliveroo, Just Eat — lands on the same thermal printer in the same order. The printer never asks where the ticket came from. That is BentoPOS, doing its job.

Context

UK independent takeaways are running on an accidental stack. A typical Friday night service involves the till from one vendor, the online ordering plugin from a second, the Deliveroo and Uber Eats tablets from third and fourth, the phone line from a fifth, and the printer driver that has not been updated since 2019. The British Takeaway Campaign estimates the sector at over 50,000 outlets and around £9.9 billion in annual turnover, with most of the long tail run by single families on margins under ten percent. Every minute lost to a screen mismatch at peak service is a minute the wok is not moving.

The category is also disproportionately first-generation immigrant-owned. The technology was not built for them. Aggregator tablets demand pidgin English at speed. Postcode entry on a US-built ordering platform breaks on UK conventions. The till SaaS bills $89 a month per terminal and assumes a North American restaurant that takes table reservations and prints customer-facing receipts. None of that is a UK takeaway.

The result is a category running on goodwill. The chef knows the menu. The owner knows the customer. The technology in between is a liability the family routes around by shouting.

The problem

A real shift looks like this. Order one comes in from the website. Order two arrives at the Deliveroo tablet. Order three is a phone call. Order four is on the counter in person. The chef behind the wok needs to see them in the order they arrived, with the right items, the right notes (“no MSG”), the right address for delivery, and the right time the driver should leave. Most of the time the chef is reading three screens and a printer and trying to match four different order numbers to the same family.

When the system fails it fails badly. Orders are doubled because two tablets did not sync. Orders go to the wrong address because the postcode was typed into a US SaaS that did not validate. The wrong dish is fried because the third-party ordering site sent a menu item the kitchen retired three months ago. The customer phones to complain. The owner refunds. The margin disappears.

Custom POS development is expensive. The market leaders charge enterprise prices and ship enterprise software — Toast, Square for Restaurants, Lightspeed. Independent shops sign a multi-year contract and inherit a feature set built for a 40-cover restaurant in Austin. The bespoke alternative is to hire an agency for £40,000 and end up with PHP from 2014. Neither option is the right shape for a takeaway that knows exactly what it needs and does not need anything else.

The shape required is specific: web counter, mobile clients, postcode-aware delivery, multi-channel order routing into a single kitchen queue, and a menu management surface the owner can edit in five minutes between services. Nothing on the market is that thing for under £200 a month.

What we built

BentoPOS is a point-of-sale system written for the real shape of a UK takeaway.

Web counter. A Next.js client running in the shop on whatever browser is on the till — Chromebook, iPad, a £200 Windows tablet. New orders surface in real time. The counter operator can take a phone order, edit a customer record, modify a delivery address, and route the ticket to the kitchen in the same three taps as ringing through a walk-in.

Mobile clients. Native iOS and native Android for the floor and the driver. The driver app shows the next delivery, the address, the postcode-validated drive distance, and the ticket details for confirmation at the door. The floor app handles ad-hoc counter sales, refunds, and end-of-shift cash-up.

Single server. A Node service holds the menu, the prices, the delivery zones and the customer history. It receives orders from every channel — the in-house website, the phone (manual entry on the counter), and aggregator integrations designed for Deliveroo and Just Eat — and routes every incoming order into a single kitchen print queue. The chef sees one stream of tickets, in the order they arrived, with channel-coloured headers so the eye can still pick out a Deliveroo from a phone order without slowing down.

Postcode-aware delivery. A self-contained postcode dataset handles delivery-zone validation. A customer in DT4 enters their postcode at checkout, the system confirms whether the shop delivers there, returns a delivery fee based on the zone the postcode belongs to, and pre-populates the address fields for the driver app. UK conventions, not US zip-code assumptions.

Ticket previews. Before any printer fires, the system renders the ticket the chef will see — full character count, escape codes, line wraps, the lot. The ticket-previews/ package in the monorepo is what made this practical: a thermal-printer ticket is a finicky thing, and seeing what the kitchen will read before sending the print job has prevented a dozen jam-related Saturday nights.

Menu management. The owner edits the menu in a web admin surface. Price changes ripple to every channel — counter, website, mobile — in the same minute. Items can be hidden ad-hoc when something runs out at 9pm.

It powers Queenie’s Mayflower in production today. Burnt fingers and burnt orange.

Architecture

The repo is a monorepo with five primary packages — client/ (the web counter), server/ (the Node backend), ios/ (the floor and driver app), android/ (same), ticket-previews/ (the thermal-print rendering test surface) — plus postcodes/ for UK delivery-zone data and MF_Menu for the Queenie’s menu source. The structure favours a single deployment target with shared types across web and native, rather than a microservice spread that would be unmaintainable at this team size.

Server. Node + Express + TypeScript. Postgres for persistent data (orders, customers, menu items, delivery zones), Redis for the real-time order queue. WebSocket from the server pushes new orders to every connected client — counter, kitchen display, driver app — so a ticket placed on the website appears on the chef’s screen within milliseconds of payment confirmation.

Web counter. Next.js with React. Server-sent components for the menu and customer records, client components for the order queue and live ticket view. The kitchen-display variant runs on a separate route designed for a wall-mounted screen behind the wok — large type, high contrast, no UI chrome.

Native clients. iOS in Swift, Android in Kotlin. Both consume the same REST endpoints and subscribe to the same WebSocket channel as the web counter. The driver app uses native maps for routing — Apple Maps on iOS, Google Maps on Android — and only requests location during an active delivery.

Aggregator routing. Designed to ingest order webhooks from Deliveroo and Just Eat through their respective integration APIs and to push status updates back. The system is built for this; commercial agreements with each aggregator are negotiated per shop rather than across the platform.

Printing. Designed for ESC/POS-compatible thermal printers over network. The ticket-previews/ package lets the team render a candidate ticket in the browser before deployment, so a new menu category or a new aggregator does not break the kitchen on its first night.

The architectural posture is deliberate: a small, owned, well-tested codebase rather than a sprawl of third-party SaaS dependencies. The shop’s data is in a Postgres database the studio can back up; the network printer is a £180 hardware purchase; the iPad on the counter is interchangeable.

How it works (the short version)

• Multi-platform clients — Next.js web counter, native iOS, native Android, all consuming one server
• Real-time order routing from web, phone, and supported aggregators into one kitchen print queue
• UK-specific — bundled postcode datasets for delivery-zone validation and address pre-fill
• Ticket-preview tooling — render what the chef will see in the browser before any printer fires
• Menu management — owner-editable, ripples to every channel in the same minute
• Stack — Node + Express + TypeScript server, Postgres + Redis, Next.js web, Swift iOS, Kotlin Android

Live behaviour today

In production at queenies.food. One restaurant on it today — Queenie’s Mayflower, Weymouth — running through a full service Friday and Saturday for several months. The system handles website orders, counter orders, and phone orders through the same kitchen queue. Aggregator integration is wired in the codebase; live cut-over per channel is paced to the shop’s commercial calendar.

Two more independent takeaways are in the pipeline, both within the Bento Labs network of family operators. Each rollout is hand-walked: install the counter, install the printer, import the menu, train the family on the admin surface, then a soft launch week before the system carries the full Friday.

What’s next

• Second shop deployment (Q3 2026). First customer outside Queenie’s. New menu structure, new delivery zones, validates the multi-tenant data model. Same codebase, configuration only.
• Aggregator cut-over (Q3–Q4 2026). Deliveroo and Just Eat order ingestion goes live for the first shop with sufficient volume to justify the per-channel onboarding. The architecture is ready; the commercial work happens shop by shop.
• Customer-facing app (Q1 2027). A direct-order app for the shop’s regulars — reorder favourites, saved addresses, loyalty mechanics. Replaces a meaningful slice of the aggregator commission for repeat business.

Tech stack

• Backend — Node.js, Express, TypeScript, Postgres, Redis
• Web counter — Next.js, React, Tailwind, WebSocket client
• iOS — Swift, native maps, push for new-order alerts
• Android — Kotlin, native maps, push for new-order alerts
• Printing — ESC/POS over network, ticket-previews/ rendering test surface
• Data — bundled UK postcode dataset, Postgres for customers/orders/menu/zones
• Infra — single-tenant deployment per shop; backups and updates managed centrally

Status

In production at queenies.food. One restaurant on it today, two more in the pipeline. Built quietly, sized for kitchens we know personally.

Why this matters for Bento Labs

BentoPOS is the kitchen compartment of the bento — and the most direct expression of the studio’s “build for people we know personally” posture. Bento Labs’ own commercial spine is rooted in the same family of restaurants the POS now runs. The bento philosophy is that one studio holds work across radically different domains — housing, commerce, hospitality, mental health — by keeping each compartment small, opinionated, and shaped to the specific person on the other side. BentoPOS is what that looks like when the person on the other side is the chef behind the wok at the Mayflower.