A family-owned restaurant: orders transformed, errors dramatically down

Discovery ran the way it has to in a restaurant that never stops serving. Instead of booking Farid into meetings, Merilsoft worked on site while service was actually running — watching a cashier key orders by hand at the counter, following a paper ticket back to the kitchen, and paying attention to the ones that came back wrong. Farid walked the menu boards between services and answered what the boards couldn't: which combos the kitchen actually allows, which modifiers cancel each other out, why a particular dish is never fired a particular way. That was the whole requirements phase — watch the work where it happens, then ask the one person who knows why it works that way.

Two things came out of it. The first was that the restaurant's real menu didn't exist anywhere on paper. The boards listed dishes and prices, but the rules — the combinations the kitchen honors and the ones it quietly refuses — lived only in Farid's head and in the habits of the staff who had worked there longest. The second was that the errors weren't landing at random. They gathered at two points: a large party splitting modifiers across courses, and a delivery order being re-keyed off the second tablet. Both were the same moment — a cashier transcribing an order instead of just taking one.

Those findings set the shape of the build. Because the combo rules weren't written down anywhere, the first two weeks went into pulling them out of Farid's knowledge and encoding them properly — which is why the modifier engine ended up as a relational schema rather than a flat list of menu items, since the conflicts needed somewhere to live. And because Friday and Saturday dinner carry the restaurant, Merilsoft sequenced the rollout to keep those nights for last: a pilot on two slower weeknights, the paper tickets still on standby at the register, and the delivery-app integration held back to the final week, so the counter flow had already survived real volume before a second order source was pointed at it.

The manager-PIN control on voids and reprints was never on the objective list. It came out of watching the counter: a mis-keyed order could slip straight through to the kitchen with nobody the wiser, and the void and the reprint at the register were where that gap lived. Gating both behind a manager PIN closed it, and closed it without standing up a full staff-account system — no logins to issue, no password for a new hire to forget on their first Friday. Farid never asked for a control on voids. He has one now, and it costs him nothing on the nights nothing goes wrong.

The bigger asset is the menu itself. Two weeks of digitization turned a set of boards and one man's memory into a schema that spells out every dish, size, modifier, and combo rule the kitchen honors. That is now something the restaurant owns rather than something it remembers. A price change or a new dish gets entered once, and the register and the kitchen display work from the same definition of it — and if Farid isn't on the floor, the rules don't leave with him.

Two pieces of the build ended up more general than the problem they were written for. The delivery integration normalizes third-party orders into the restaurant's own queue over webhooks, so the queue doesn't much care which app an order arrived from — pointing another one at it is closer to a mapping job than a rebuild. And the offline queue on the counter tablet, added because the restaurant's Wi-Fi had never needed to be reliable, means a brief drop no longer stops order entry: tickets keep reaching the kitchen and sync back to the dashboard once the connection returns. Nobody asks for that until the night it matters.