Not a POS problem
The cafe had no physical menu cards, so every order depended on a staff member being free to explain what was available. There was no visibility into which items sold well, and no clear read on daily revenue. During peak hours, that turned into confusion, delays, and decisions made on gut feeling.
The obvious fix looks like a full point-of-sale system. I didn't think that was the real problem. A small cafe with limited staff doesn't need inventory modules or multi-location reporting. What the owner actually needed was faster ordering, fewer interruptions, and simple numbers to make daily decisions from.
Two numbers, not a suite
Full POS software solves problems this cafe didn't have, costs more, and takes longer to learn than a small staff can absorb. I scoped this down to two things: a QR-based digital menu customers use directly, and a dashboard showing best-selling items and daily revenue. Nothing else. Once a dashboard exists, it's easy to keep adding metrics. I kept it to the two numbers that actually change what the owner does the next day.
Plain, on purpose
I avoided heavy animation, complex visuals, and advanced interactions on purpose. For a customer ordering for the first time with no app to download and no one to explain it, a flashy interface is friction, not delight. The design leans on clear food photos and the smallest possible learning curve instead.
What shipped
The system shipped and the cafe adopted QR-based ordering. Staff spent less time taking orders directly. The owner could finally see which items were actually selling, with a clearer read on daily revenue than before.
I'm not putting percentages next to any of this. The client asked that specific values stay confidential, and I'd rather say that plainly than dress up a vague claim to look quantified. The qualitative shift was real, faster ordering, fewer staff interruptions, decisions the owner could see the reasoning behind.
What I took from it
Another lightweight tool built under real operational constraints.
See the surveyor web app case study