About the project
A point of sale suite for restaurants, retail and grocery, built around a local hub so a till keeps selling when the internet drops. A new sector is a settings profile rather than a fork.
My role: Architect and full stack developer of the three applications, the offline synchronisation model and the cloud deployment.
I built this suite around a constraint that most cloud point of sale products quietly ignore: a shop cannot stop selling because the connection dropped. In Tunisia that is not an edge case, it is a Tuesday. So the architecture puts a local hub between the tills and the cloud rather than making every sale depend on a round trip to a data centre.
The suite is a Turborepo monorepo with three applications. The till and back office run as a React 19 progressive web app with Zustand for state and Workbox for offline caching. The API is Express 5 with Drizzle over PostgreSQL 18 on Cloud SQL, deployed to Cloud Run. Between them sits a desktop hub built with Electron, embedding its own Express server and a better-sqlite3 database, which serves every till on the local network and reconciles with the cloud once connectivity returns.
One product had to cover restaurant service, general retail and grocery, which are three different ways of selling. Rather than fork the codebase per sector, I modelled the differences as configuration and kept a single catalogue, a single pricing engine and a single sales journal. Authentication uses Firebase with custom claims carrying the tenant and the role, so an operator with several shops manages them from the same account without any data crossing between them. The suite runs in production for one operator today, and taking on a second one means creating a tenant and picking a sector profile, not standing up another system.
Main features
- 🔌 Offline first selling: A local Electron hub with an embedded SQLite database keeps every till operating when the connection is gone.
- 🍽️ Multi-sector by configuration: Restaurant service, general retail and grocery run on one codebase, their differences expressed as settings.
- 📱 Installable till interface: The cashier screen is a progressive web app cached by Workbox, so it launches like a native application.
- 🏪 Multi-tenant by design: Firebase custom claims carry the tenant and role, so an owner runs several shops from one account with no data crossing over.
- 🔄 Two way reconciliation: Local sales replay to the cloud once connectivity returns, and catalogue changes flow back down to the hub.
- ⚡ Serverless API on Cloud Run: Express 5 with Drizzle over PostgreSQL 18 scales to zero between rush hours and back up during service.
- 🧾 Single sales journal: One catalogue and one pricing engine feed every sector, so reporting never has to merge incompatible sources.
- 🚦 Status today: One operator runs the suite in production. A second one is a tenant to create and a sector profile to pick, not another system to stand up.
Problems and solutions
Problem: Cloud point of sale products stop taking payments the moment the internet fails, which in practice means the shop stops trading. Fully local systems avoid that but leave the owner with no consolidated view across shops.
Solution: I placed a local hub between the two. Tills talk to a hub on the shop network that owns an embedded SQLite database, so selling never depends on the internet. The hub reconciles with PostgreSQL on Cloud SQL as soon as the link is back, which preserves the consolidated multi shop view.
Problem: Restaurants, general retail and grocery sell in genuinely different ways, and the usual answer is a separate product or a forked codebase for each. Every fork then drifts, and a fix written for one sector has to be ported by hand to the others.
Solution: I modelled the sector differences as configuration over a shared catalogue, pricing engine and sales journal. One codebase serves all three, and a new sector is a settings profile rather than a fork. That is also what makes the suite sellable to a second operator without a second codebase to maintain.
