Case study
This project is our own product. We say so, because it is what makes the difference: we did not only build it, we run it and answer for it when something fails.
There is no shortage of POS systems for hospitality. The problem is rarely the feature list — it is the maths underneath: licence fees per device per month, add-on modules for things that ought to be standard, and contracts a seasonal business cannot escape over winter. On top of that, interfaces designed for full-time staff rather than for the weekend help standing behind the bar for the second time.
Developing your own POS system is not a decision to take lightly — Austrian cash register regulation alone turns a manageable project into a regulated one. We did it anyway, because we wanted two things you cannot buy in: full control over how the system feels during actual service, and a product that lets our way of working be examined without a client having to give permission first.
The key design decision was to give guests nothing to install. That is exactly where most ordering systems fail: anyone asked to download an app, register and confirm permissions would rather order from a member of staff — and the whole investment was wasted. With ScanOrderPay the QR code opens the menu directly in the phone browser. That rules out some capabilities a native app would have, but it is the difference between a system that gets used and one that would have to be installed.
Austrian cash register regulation requires cash transactions to be signed and logged without gaps. That cannot be bolted on later without rebuilding the data model — so signing was part of the first design, not the second. We apply the same logic in client projects: requirements that come from legislation belong in the architecture, not in the rework.
ScanOrderPay runs in restaurants with table service, at fire brigade festivals, on trade stands and at farm shops. Those are four fundamentally different workflows: a restaurant has fixed tables and trained staff, while at a club festival the volunteers change hourly and nobody has time for a briefing. A system meant to serve both has to be simple enough by default to work without explanation — and still offer enough when an operation needs more. Resolving that tension took more effort than any individual feature.
A POS system is not finished when it ships. Tax requirements change, devices get replaced, operating systems update. We maintain the system continuously — and because we run it ourselves, faults hit us directly rather than arriving as a ticket. That shapes how carefully you build.
ScanOrderPay has its own brand and its own website. You will find the full feature set, terms and usage examples there.
Outcome
The system is in use and continues to be developed.
For you as a client the more telling figure is a different one anyway: we keep a product running whose failure hits us directly. Anyone in that position builds differently — more carefully where it hurts in operation, and more sparingly on features nobody needs.
What transfers
Peak hour, rotating staff, guests with no prior knowledge. The question is not whether the system works under ideal conditions, but whether someone seeing it for the first time can operate it.
Cash register rules, GDPR, retention periods — leaving these to the end gets expensive.
One shift on the floor teaches more than three workshops. That is why our discovery phase is not a paper exercise.
If you need a system that has to hold up in live operation, tell us about it. In the intro call we will point out where the pitfalls are.
