The menu that had to change in one place

The situation

RPM Patio Pub & Grill in historic downtown Newnan, Georgia. Fifteen taps, a patio, live music and open mic nights — and a menu that moves, because specials change, prices change, and things run out in the middle of service.

They wanted the menu on screens above the bar, and they wanted to be the ones changing it. Deployed and running in the venue; the boards and the admin are behind the pub's own login, which is why there is nothing to link to here.

Built for RPM Patio Pub & Grill.

What was actually wrong

Digital signage usually means a PDF on a television

The normal route is to export a design file and display it full screen. The person who needs to change it cannot, it is the wrong shape for a second screen of a different size, and nothing about it knows that an item ran out ten minutes ago.

The menu changes faster than anyone will redesign it

If updating the board means opening a design tool and re-exporting, the board is wrong by lunchtime. Once a board has been wrong a few times, staff stop pointing customers at it, and the screens become expensive wallpaper.

A pub price is rarely one number

One or two pretzels, half a Reuben, salmon instead of chicken, extra beer cheese. A single price field either lies about that or refuses to let the item exist, and both of those end up being solved on a chalkboard.

The cheap television is part of the problem

Signage runs on inexpensive streaming sticks, on venue wifi, in a building where the power goes off. Anything that needs a member of staff to go and restart it is not a signage system — it is a chore with a screen attached.

What we built

One admin the owner actually runs

Items, categories, tags and modifier groups, with 86 and un-86 as a single toggle. Bulk price changes go through a mandatory preview before they apply, and every change lands in an audit log with one-click revert — so the answer to "who changed that and can we put it back" is a button rather than a phone call.

Screens that pair themselves

A code appears on the television, gets typed into the admin once, and the screen then polls for changes and re-renders only when something has actually changed. Scheduling means one screen can show a different board at a different time of day.

Built to survive the room it lives in

When the wifi drops it keeps the last board on screen and retries with backoff, showing an offline dot sized to be visible up close and invisible from across the bar. After a power cut it resumes on its own, and it reloads itself at four in the morning so a cheap TV browser never runs out of memory during service.

A price fail-safe rather than a guess

Where an item's price is genuinely ambiguous, the board shows no price at all instead of a possible wrong one. A blank is a question a customer asks; a wrong number is an argument at the till.

A guest menu from the same data

A phone menu behind a QR code, generated from the same items as the boards, with internal tags — happy-hour-eligible, domestic — structurally unable to appear on it.

Three ways in, one set of rules

The admin, a scoped API for anything the pub wants to connect later, and an assistant integration that lets someone 86 an item by saying they are out of it. All three run through the same functions and write to the same audit log, so none of them is a side door around the others.

This engagement has no measured figures we can publish, so none are shown. We are happy to provide references on a call.