There's a specific kind of humility that comes from watching someone use your software while eleven order tickets curl in the kitchen window and a customer waves for the bill. Every assumption you made at a desk gets stress-tested in about ninety seconds. We've been doing this to ourselves for a while now — building KinDee POS during the day and depending on it during service — and it has quietly rewritten most of what we believed about building software for real businesses.
These lessons apply well beyond restaurants. If you're commissioning software for any busy, physical, staffed business — a clinic, a salon, a warehouse — I'd argue they're the difference between a tool that gets used and a tool that gets worked around.
1. Nobody reads the screen
This was the hardest one to accept. As developers, we write helpful text: confirmation messages, explanatory labels, friendly empty states. During a rush, staff read none of it. They navigate by position, color, and muscle memory. A cashier who has used the till for two weeks could operate it blindfolded — and effectively does.
The consequences are concrete. Moving a button in an update is a breaking change, even if the new position is "better." A confirmation dialog doesn't make people pause and think; it teaches their thumb one extra tap in the same spot. If an action is genuinely dangerous — voiding a paid order, say — the protection can't be a message. It has to be a different motion: a hold-to-confirm, a manager PIN, something the hand can't do on autopilot.
2. Design for the worst hour, not the demo
Every piece of business software demos beautifully at 10 a.m. with one test order and full attention. That environment is fiction. The real environment is 7:40 p.m., greasy fingers, a cracked screen protector, one bar of Wi-Fi at the far table, and a trainee on their second shift. We now judge every feature against that hour, and it filters ruthlessly: fewer taps beats more options, big targets beat elegant density, and anything that can wait until after service — reports, settings, sync — gets out of the way of the one thing that can't, which is taking the next order.
3. Staff turnover is a feature requirement
Hospitality staff move on — that's the industry, in Vientiane and everywhere else. It took us embarrassingly long to treat this as an engineering constraint: the software must be learnable in one shift, because you will be teaching it again next month. Anything that needs a training manual will eventually be operated by someone who never saw the manual.
This is also, quietly, an argument against feature-count as a buying criterion. Every feature your staff don't use is not neutral — it's one more screen between a new hire and competence. When we evaluate adding anything now, the first question isn't "is it useful?" It's "is it worth its weight in training time?"
4. The owner uses the software at 1 a.m., on a phone, in bed
We assumed owners would sit down with dashboards. They don't — we don't, and we built the dashboards. What an owner actually does is open a phone after close and want three numbers: today's sales, versus a normal day, and anything weird — a big void, a discount that shouldn't exist, a till that doesn't balance. Ninety seconds, half asleep. So the daily summary became one screen, readable at arm's length, worst news first. The deep reports still exist; they're for the once-a-week coffee, not the nightly pulse-check.
Software for a busy business has two users: the hands during service, and the eyes after close. They want opposite things, and the design has to serve both.
5. The menu is a living organism
On our first menu-editing screen, changing a price took five taps and adding a lunch special took a form with nine fields. We'd built it as if a menu changes quarterly, like a config file. Menus change constantly: an ingredient doesn't arrive, a dish flops, a supplier raises the price of limes again. If editing is slow, reality drifts away from the system — staff start memorising "the real price," the kitchen keeps exceptions in their heads, and your reports slowly stop describing your restaurant. Making everyday edits trivially fast isn't convenience. It's what keeps the data true.
6. Trust is binary
Software earns trust slowly and loses it in one incident. The day a till total doesn't match the cash drawer, staff stop believing the system — and once they keep a paper backup "just in case," you're paying for software while running on paper. This is why we're fanatical about the unglamorous parts: sums that always reconcile, an audit trail for every void and discount, an offline mode that doesn't lose orders. Nobody chooses a POS for its reconciliation logic. But it's the reconciliation logic that decides whether they're still using it in a year.
What this means if you're buying software
You can't run a two-year experiment like we accidentally did, but you can borrow the conclusions. When you evaluate any system, skip the feature tour and ask to see the worst hour: how many taps for your most common operation? Could a new hire learn it in one shift? What does the owner see on a phone at 1 a.m.? What happens when the drawer doesn't match? The vendors with good answers have stood behind a counter. The others have stood behind a projector.