Offline-first POS for hospitality

The problem

Most POS systems sold to small businesses share a few familiar flaws. They require a web dashboard to manage anything that matters - implying a laptop in the back office, not the phone in your pocket. They lock operators into the vendor's own payment processor. They charge premium pricing and tie that pricing to long contracts. They ship with broken or missing features (inventory that doesn't reconcile, reports that don't add up). And almost universally, they require an internet connection to do their actual job: take payments.

For the small operator - a café, a bar, a barber, a corner shop - these are real costs. A dropped wifi connection becomes a stalled sale. A change to product pricing requires going home to a laptop. A payment processor lock-in becomes a permanent tax on every transaction.

This product was built to fix all of that, for SMBs who can't afford friction at the till.

The approach

The product is built around three deliberate choices: mobile-first management, offline-first operation, and provider-agnostic payments.

Native Android for the cash register and management. The till and the management dashboard live in the same native Kotlin app. Operators can run a register, manage inventory, adjust pricing, view analytics, and onboard staff - all from a phone, on the floor, between customers. The web dashboard exists as an optional add-on for desk work, not a dependency.

Offline-first by design. The cash register works without an internet connection. Setup requires connectivity: an admin signs in, assigns a device to a cash register, and the device pulls down everything it needs - products, prices, taxes, tables, staff, fiscal configuration. After that, the device operates indefinitely offline. Receipts, sales, stock movements all persist locally in SQLite (via Room) and sync to the server the moment connectivity returns.

The sync layer is the unglamorous engineering core of the product. It handles conflict resolution between devices, fiscal rules that allow delayed fiscalisation (Croatia requires every receipt to be fiscalised "as soon as possible" - a non-trivial constraint), and the boundary between online-when-possible and offline-when-necessary without losing data or duplicating writes.

Bring your own payment processor. Most POS vendors force their own card processor on the operator. This one integrates Stripe, Square, Teya, and SumUp out of the box, with more in the roadmap. Operators keep their existing merchant relationships.

Multi-location and multi-country, by architecture. Branches, warehouses, cash registers, and inventory all model real-world hierarchy. One company can run multiple branches, each with their own warehouse and tills. Inventory is tracked per warehouse. Fiscal compliance is pluggable per country - currently supporting Croatian and UK fiscal regimes, with new regions added as fiscal-module additions rather than re-architecture.

Building the Croatian fiscalisation flow first was deliberate. Croatian fiscal law is among the strictest known: every receipt must be cryptographically signed, transmitted to the tax authority, and reconciled - including offline-deferred receipts. Once Croatia was solved, adding the UK (a simpler regime) was straightforward. The architecture inverts the usual fiscal pain curve.

The outcome

The platform is in final QA with five pilot operators across hospitality and retail. It supports two countries (Croatia, UK) with the multi-country architecture proven on the harder one first. The app has run in pilot for three months without a single crash. Onboarding is a two-step process inside the app - no sales call required.

The first sales partnership is in motion, with the partner planning to operate their own venue on the same platform - a credibility signal we'd take over any number of marketing pages.

Next: shipping to general availability, expanding fiscal coverage to the next EU regions, and rolling out the planned payment processor additions.