A menu that changes without a print run
Cafés and restaurants kept their menus on paper, so changing a price meant reprinting everything and living with whatever was on the table until the next print run. Top Menu put the menu behind a QR code on the table — and behind that, a platform each business runs itself.
What was wrong
A printed menu is fixed the moment it leaves the printer. A price rises, a supplier stops delivering, a dish sells out — and the menu on the table still says otherwise until somebody reprints the lot. For a café changing things weekly that is a standing cost, a standing source of small embarrassments with customers, and a quantity of wasted paper nobody felt good about. The alternative most venues had was a PDF on a phone, which solves the printing and none of the rest.
What made it awkward
- Three audiences, one system. A diner wants a menu that opens instantly on a phone with bad signal. Staff want a till-side tool that never gets in the way at a rush. The client wanted to run hundreds of venues from above. Each would have been a reasonable product on its own.
- No two venues wanted the same thing. Some wanted online ordering and payment; some wanted the menu and nothing else, and were adamant about it. A single fixed feature set would have lost half the market either way.
- The client is not technical, and running a platform of this size cannot depend on a developer being reachable. Anything routine had to be something he could do himself.
- It was live and earning from early on. Five years of change had to land underneath a product that venues were using during service.
What I built
- A menu a diner opens by scanning the QR code on their table — no app to install, no account to make, and fast enough to be usable on a phone on café wifi.
- Ordering and payment on the same screen, so a table can order without waiting to catch someone's eye — switched on per venue, because plenty of them did not want it.
- A dashboard each business runs itself: menu and prices, staff accounts with access levels so a floor employee sees less than a manager, and reports on income, sales and walk-ins.
- A platform dashboard above all of it, so the client can onboard a venue, change what it is allowed to use, and see across the whole estate without opening a terminal or asking me.
- The infrastructure, deployment and monitoring underneath — the part nobody sees until the menus stop loading during a Friday dinner service.
- Documentation and mentoring for the client's own developers, so the product had more than one person who understood it.
Decisions worth explaining
The web, not a native app
Nobody installs an app to read a menu they will look at for four minutes. A QR code that opens a page is the only version a diner will actually use, and it removed the app stores from the release path entirely.
The trade-off: Gave up push notifications and native payment sheets, both of which came up more than once.
Features switched on per venue, rather than one product for everyone
A restaurant taking online orders and a café that just wants its menu readable are different businesses with different fears. Letting each turn things on kept both, instead of building for the average of the two and suiting neither.
The trade-off: Every feature has to work with the others absent, which makes the system harder to reason about and considerably harder to test.
A platform dashboard the client operates himself
A platform where the owner needs a developer to onboard a customer has a bottleneck built into it, and the bottleneck was me. Building the boring administrative screens meant he could run the business at his own pace.
The trade-off: Months of work that produced nothing a diner would ever see, argued for on the grounds that it would stop mattering who I was.
Mentoring their developers instead of staying the only one who knew it
Five years is long enough that being irreplaceable stops being an asset to the client and becomes a risk to them. Bringing their people up on the codebase was the responsible end of the engagement, not a threat to it.
The trade-off: Slower delivery while it was happening, and it deliberately made me easier to replace.
How it ran
First months
The diner-facing menu and the QR flow — the piece that had to be right before anything else was worth building.
Year one
The business dashboard: menu management, staff accounts and access levels, and the first reports.
Years two and three
Ordering and payment, per-venue feature control, and the platform dashboard that took day-to-day administration off me.
Years four and five
Scale and handover. Infrastructure and reliability work as the estate grew, then documentation and mentoring so the client's developers could take it forward.
What changed
What I would do differently
I built the venue dashboard before the platform dashboard, which meant that for the first couple of years every new venue came through me. It felt like the right order — the thing customers touch first — but it made me the bottleneck in someone else's growth, and I stayed the bottleneck longer than I should have. The administrative screens were the least interesting work in the project and would have been worth doing a year earlier than I did them.