Why we deliberately do not build a big POS

If you have ever evaluated point-of-sale software for a small restaurant, you will recognise the pattern. The vendor's deck shows fifty features. The configuration screen has hundreds of settings. The recurring fee is calibrated for a chain. After three months you and your team are still using maybe twelve features — but you are paying for all fifty, and tripping over the rest every shift.

This is not an accident. It is what happens when one product has to satisfy a venture-funded vendor's growth curve and serve a single 40-seat restaurant in central Kuala Lumpur. The two needs simply do not point in the same direction.

What "minimal POS" actually means

When we say "minimal", we do not mean stripped-down or low-quality. We mean: only what this restaurant needs, and nothing else. Three concrete examples from our own deployments:

• An izakaya counter where the chef wants the order entry to follow the actual flow of an omakase — not a generic "table → ticket" interaction. So we model courses, not just items.
• A small lunch-and-dinner concept where the kitchen runs two distinct stations. The POS should route the right items to the right printer with the right format. No "rules engine" needed — just a clear, hardcoded mapping.
• An owner who closes the till herself every night and just wants three numbers on the home screen: revenue, top dish, and the cash variance. That is the home screen. Not a "dashboard module".

What we leave out

The list is at least as important as what we put in:

• No multi-tenant feature flags. Each store gets the build that fits it.
• No "configurable everything". If a setting only one type of restaurant needs, we hardcode it for the ones that need it and leave it out of the others.
• No theme engine, no plugin marketplace, no roadmap of someday-features. We ship what is needed now.

What we keep small intentionally

• Database. A single PostgreSQL instance per store, sized to the actual transaction volume. No microservices.
• Codebase. One TypeScript codebase per store family, sharing common modules where it is genuinely the same problem.
• Operational footprint. One server, one backup pipeline, one monitoring view. Boring on purpose.

Why this works for small operators

The result is software that fits the operation rather than asking the operation to bend around it. It is also, importantly, dramatically cheaper to own. A single store running our minimal POS is paying a fraction of what it would pay a generic enterprise POS vendor — and the cost stays predictable as the operation grows.

This approach is not for every business. A 200-store franchise needs different software, and we are not the team that should be building it. But for the bulk of independent restaurants and small chains in Malaysia? Right-sizing the POS is one of the highest-leverage decisions an owner can make.

Working on POS for your own operation? Get in touch — we are happy to compare notes.