Overview
Most restaurant software is demonstrated at 11 AM in a quiet room. It's judged at 8 PM on a Friday, and Red Rock was built for that second scenario.
The problem restaurants describe isn't usually we need a POS, it's that dine-in runs on one system, takeaway on a notepad, and online orders arrive through an aggregator's tablet propped up next to the till, and at the end of the night someone has to make three sets of numbers agree. Red Rock needed a system built for the busiest hours, not the sales demo.
Challenge
A dine-in order, a takeaway order and an online order are commercially different but operationally identical, they all become food a cook has to make in the right sequence, and any system that keeps them in separate queues pushes the reconciliation work onto humans during the busiest hours. Staff turnover is real and training time is short, restaurant software that needs a manual has already failed, new staff need to be productive on it within a shift, not a week. Menus also change constantly, prices move, items sell out mid-service, specials appear, and if changing a price requires a developer the system gets worked around within a month, and the workarounds become the real process. Service doesn't pause for software either, a POS is a system where slowness at the wrong moment costs a table, so it has to be quick, forgiving of mistakes, and impossible to lose an order in.
Approach
Every order was modeled as a single object with a channel attribute, rather than three parallel order systems sharing a database, a dine-in order and an online order are the same record with different origins, which means one queue, one status flow, and one set of totals at the end of the night, a modeling decision made in the first week that determines whether the reconciliation problem exists at all. Menu management was built for the restaurant's own staff from the start, categories, items, prices and availability all editable by the people who need to change them, at the moment they need to change them, held to the standard of whether the business can run a normal day without calling the developer. The interface was designed for speed under pressure rather than visual sophistication, large targets, minimal steps to a completed order, common actions reachable without hunting, since software used during service is judged on how it behaves in the worst ten minutes of the week, not the best.
Result
Red Rock is in daily use in a working restaurant, the only test that matters for operational software, with one order queue across dine-in, takeaway and online replacing what used to be per-channel reconciliation, and the menu managed entirely by restaurant staff rather than developers. Specific figures for orders processed and time in service are available on request.
