What an offline-first point-of-sale app has to get right

What an offline-first point-of-sale app has to get right

A shop on a Saturday afternoon. The connection drops. The queue is six people deep. The cashier finishes the sale, prints the receipt, and the stock count updates.

Weza POS is built on the assumption that the second half of that story is the normal case, not the outage case.

The constraint moves into the data layer

Most point-of-sale apps are thin clients. The till asks a server for the price, the server records the sale, the server adjusts inventory. When the server stops answering, the till stops being a till.

Weza POS puts the database on the counter computer. Checkout, barcode scanning, receipt printing, and stock deduction all run locally. Cloud sync is something you switch on, not something the checkout path waits for. Backup files are local, and data export is available from the app.

That single decision pushes work into places a cloud-first design never has to think about:

• The local database is the source of truth, so reconciliation is your problem.
• Backups are the shop's responsibility unless they pay for off-site.
• Reports have to be computed from local data, not queried from a warehouse.

Hardware is where the ugly parts live

POS integrations get difficult at the device layer, and this is the part developers underestimate.

Thermal receipt printers in this class speak ESC/POS, which is a command set rather than a driver. You are writing bytes to a device, whether that is a serial port, a USB endpoint, or a network socket. The 58mm and 80mm roll widths are the two common form factors.

Barcode scanners in keyboard-emulation mode present as a keyboard, so they need no driver. That is why "works with a standard USB scanner" is achievable. Cash drawers are usually kicked by a pulse sent over RJ11 or RJ12, often through the printer rather than directly.

None of that is hard on its own. It gets hard when you have to support the long tail of hardware a real shop already owns.

Shipping the same app to three platforms

The builds are an .exe for Windows, a .dmg for macOS, and .deb or AppImage for Linux. ⟨verify⟩

Desktop distribution means you own updates, code signing on two platforms, and whatever the Linux packaging story turns into. A web app avoids all of it, which is the trade you make for working offline.

The licence model is a product decision

The Pro tier is a one-time payment per device. The Business tier is a subscription that adds cloud backup and sync, plus the multi-staff features. ⟨verify⟩

That split is coherent. Offline resilience is what you buy once. Off-site durability is what you rent. A shop that wants both a local database and automatic remote backup pays monthly, and a shop that is willing to run its own backups does not.

Questions I would ask before picking it

If you are evaluating this for a shop you support, these are the ones that decide it:

1. How does sync resolve conflicts? If two tills sell the same last unit while both are offline, what does the merged inventory look like?
2. Is the local database encrypted at rest, and where do the keys live?
3. What is the restore path from a backup file, and how long does it take on a busy morning?
4. Which printers and scanners have actually been tested? The compatibility list matters more than the feature list.
5. Is sync one-way or two-way? One-way upload is easier to reason about and easier to recover from.
6. What happens to reports and history if a subscription lapses?

The site answers some of these and not others. ⟨verify⟩

Where this design fits

One or two tills, a fixed counter, and an internet connection you cannot depend on. A pharmacy that cannot hold a queue while a connection resets. A bar on a Friday night.

If you are running a cloud POS in a place with reliable connectivity, the offline architecture buys you less. If you are not, it is the difference between a lost sale and a recorded one.