Dine Board
A secure digital signage platform I designed and built in-house for UC Merced Dining Services. It powers every screen at the campus's dining center, serving 5,000+ guests a day. This project significantly streamlined our team's menu update process — from a station-by-station manual update with a USB drive into a single change that hits every display in under a minute. It was later absorbed into UC Merced's official GitHub organization as campus infrastructure.
The problem
Originally my alma mater used paper menus, but over time made the change to screens — a huge step forward. That held until the way we updated those screens became the bottleneck. Every change traveled by USB stick: copy the files, walk the floor, and update each station by hand. It was slow, easy to get wrong, and menus routinely fell behind what the kitchen was actually serving, with each correction costing someone another lap across the hall.
What began as a request to make updates 'less annoying' turned out to be a workflow problem. Sitting with the people who did the updating made it clear that no amount of tidier file handling would solve it — the screens needed to update themselves.
Goals for launch
Before I'd call it shipped, four things had to hold true:
- Make a menu change once and have it appear on every screen within a minute.
- Keep the displays in sync with what the kitchen is serving in real time.
- Clear the university's security bar.
- Let dining staff run it day to day without an engineer in the loop.
Why build instead of buy
Off-the-shelf signage products exist, but each realistic option came with a procurement cycle, per-screen licensing, hosting outside the campus network, and workflows built for corporate marketing teams rather than dining staff flipping menus between meal periods. We needed something fast to stand up, shaped around stations and service times, and able to live inside campus infrastructure.
Building it ourselves put a working dashboard in front of staff in under two months and left the university owning the whole thing. That ownership mattered later, when DineBoard became the live-menu source for Tule, the campus information platform.
Conditions and constraints
The people running it are dining staff, not IT, so every workflow had to survive a shared back-office computer and a five-minute gap between rushes: sign in, pick a station, pick a meal period, upload. Anything fussier would have become a support call.
The displays are big Android units on the floor, so the client stays intentionally dumb. A screen only ever asks one thing: what's the current menu for this station and meal period? There's no local state to corrupt and no wrong screen to get stuck on.
And since staff log in every day from inside a university network, security wasn't optional: campus single sign-on in front of the dashboard, on-premises hosting, and a rate-limited content API.