Offline Point of Sale: Tills That Keep Selling When the Internet Drops

Case study

Offline Point of Sale: Tills That Keep Selling When the Internet Drops

All case studies

I built a point of sale suite for restaurants, retail stores and grocery shops that keeps every till selling during internet outages. A local hub on the shop network records each sale and syncs it to the cloud once the connection returns, and all three sectors run on a single codebase. One operator runs it in production today.

3
Sectors on one codebase
3
Applications in the suite
2
Databases kept in sync

The problem

Most cloud point of sale products quietly assume a stable connection. The moment the internet fails, the till stops taking payments, which in practice means the shop stops trading. In Tunisia that is not an edge case, it is an ordinary Tuesday.

The alternatives were not better:

  • Fully local systems keep selling offline, but leave an owner with several shops and no consolidated view of sales and stock.
  • Restaurants, retail and grocery sell in genuinely different ways. Table service, barcode checkout and weighed products usually mean three separate products or three forks of the same code.
  • Forks drift apart. A fix written for one sector has to be ported by hand to the others, and sooner or later it is not.

The approach

I designed the suite around one rule: a sale must never depend on a round trip to a data centre.

A local hub between the tills and the cloud

A desktop hub built with Electron sits on the shop network with its own embedded server and SQLite database. Every till talks to the hub, so selling continues when the internet is gone. When the link comes back, local sales replay to PostgreSQL in the cloud and catalogue changes flow back down to the hub, which preserves the consolidated view across shops.

One codebase, three ways of selling

Instead of forking the product per sector, I modelled the differences between restaurant service, general retail and grocery as configuration. All three share one catalogue, one pricing engine and one sales journal, so reporting never has to merge incompatible sources and a new sector is a settings profile rather than a fork.

Several shops, one account

Authentication runs on Firebase with custom claims carrying the tenant and the role. An owner with several shops manages all of them from the same account, with no data crossing between businesses.

A till that installs like an app

The cashier screen is a progressive web app cached for offline use, so it launches like a native application. The cloud API runs on Cloud Run, which scales down between rush hours and back up during service.

Outcome

The suite runs in production for one operator today.

  • Selling does not stop with the internet: tills keep working through the hub and reconcile automatically afterwards.
  • One consolidated view: sales from every shop land in the same cloud database once connectivity returns.
  • One product to maintain: a fix ships once and reaches restaurants, retail and grocery at the same time.
  • Ready for the next operator: taking on a new business means creating a tenant and picking a sector profile, not standing up another system.

The architecture is detailed on the multi sector point of sale project page.

Tech stack

React
TypeScript
Electron
SQLite
PostgreSQL
Express.js
Cloud Run
Firebase
PWA

Related services