The Client & The Context
Most restaurant software is demonstrated at 11 AM in a quiet room. It is judged at 8 PM on a Friday, when three tables are waiting, a delivery rider is at the door, the phone is ringing, and someone has just changed their order.
Red Rock needed a system for the second scenario. [VERIFY: what were they using before — a generic POS, paper tickets, or separate apps per channel? One line here grounds the whole story.]
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.
The Challenge
- Three channels, one kitchen — a dine-in order, a takeaway order, and an online order are commercially different but operationally identical, and any system that keeps them in separate queues pushes reconciliation 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 must be productive on it within a shift, not a week.
- Menus change constantly — prices move, items sell out mid-service, seasonal specials appear, and if changing a price requires a developer, the system will be worked around within a month, and the workarounds become the real process.
- Service doesn't pause for software — 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.
Our Approach
We designed around the order as a single object with a channel attribute, rather than building three parallel order systems that share 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. This is a modelling 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, availability — all editable by the people who need to change them, at the moment they need to change them. The test we hold ourselves to on operational software is simple: can the business run a normal day without calling us? If not, the build isn't finished.
The interface was designed for speed under pressure rather than visual sophistication: large targets, minimal steps to a completed order, and the common actions reachable without hunting. Software used during service is judged on how it behaves in the worst ten minutes of the week, not the best.
What We Built
Red Rock runs on Laravel with MySQL — a deliberately boring, dependable choice for a system whose primary virtue is that it works every single night. Staff take orders across dine-in, takeaway, and online channels from one interface; orders move through their status flow to the kitchen and out; billing produces totals and receipts.
The restaurant's team manages its own menu — categories, items, pricing, and availability — without developer involvement.
any of these that genuinely exist — table management, kitchen display screen, daily sales reporting, multi-branch support. Only include what was actually built.
Technical Decisions (and the Trade-offs)
- One order model with a channel attribute — the alternative, separate flows per channel, is faster to build and permanently more expensive to operate; we took the slower first month for the cheaper next five years.
- Laravel and MySQL, chosen for boringness — for software that runs during service, the correct technology is the one with the fewest surprises, the deepest documentation, and the largest pool of engineers who can maintain it. The trade-off is less architectural elegance in exchange for reliability and maintainability — a trade we'd make again every time.
- Custom build rather than a subscription POS — off-the-shelf POS products are mature and, for many restaurants, the right answer. A custom build earns its cost when the restaurant's workflow doesn't fit the product's assumptions, or when per-terminal monthly fees stop making sense at scale. [VERIFY: the actual reason in Red Rock's case — workflow fit, cost, or ownership.]
Results
- In daily use in a working restaurant — the only test that matters for operational software.
- One order queue across dine-in, takeaway, and online, replacing per-channel reconciliation.
- Menu managed by restaurant staff, not by developers.
- orders processed / months in service / branches
- owner testimonial
What We'd Tell Another Restaurant Owner
- Count your order channels before you buy anything — if you're taking orders in three places and reconciling at midnight, that's a software problem with a known solution, and it's costing you more than the software would.
- Judge a POS by who can change the menu — if the answer is "the developer," the system will be worked around by month two, and the workarounds will become your real process.
- Boring technology is a feature during service — nobody in a busy kitchen is impressed by an elegant architecture; they notice a screen that responds instantly and never loses an order.
