Cloud & offline · Web / Desktop / Mobile
One RESTful API backend, one PostgreSQL database, and three clients — web, desktop and mobile — sharing the same catalogue, stock, sales and reports. Each client keeps a local store and a write queue, so work continues through an outage and syncs automatically when connectivity returns.
Every client talks to the same REST API and database, so records stay consistent everywhere. Each platform also keeps its own local copy and offline queue, so a dropped connection never stops the counter.
A React application with no installation required. Full back-office: catalogue, inventory, purchasing, point of sale, transfers and reporting.
An Electron application for a till or back office, with native access to hardware that a browser cannot reach.
node-hidAn Expo / React Native app with an on-device SQLite database, for stock takes, receiving and selling away from a desk.
When the connection drops, the client does not fail — it serves reads from its local mirror, records writes in a local outbox, and shows the user exactly what has not reached the server yet. When the connection returns, that queue is replayed safely.
Reads come from the local mirror (IndexedDB on web and desktop, SQLite on mobile). Writes are appended to a local outbox with a client-generated operation id and applied to the UI immediately.
A banner reports pending and failed counts with the time of the last successful sync, so staff always know what is still only local.
On reconnect, on app foreground, on a timer, or on demand via a sync control, the queue is replayed in order. Each operation carries an idempotency key, so a retry cannot create a duplicate record.
Incremental pull deltas are merged into the local mirror, local-only ids are remapped to server ids as records are created, and failures are retained in a capped conflict log.
Two mechanisms make automatic retries safe. The server claims an idempotency key per device and operation, so a repeated request is recognised and not applied twice. A unique constraint on each client's local transaction id provides a second line of defence at the point where stock and sales are written.
A single product catalogue flows through purchasing, stock movements, inter-branch transfers, point of sale and reporting.
Captures from the running application, grouped by area. Select any image to open it full size.
The core system is the same everywhere; the differences follow from what each form factor is used for.
| Capability | Web | Desktop | Mobile |
|---|---|---|---|
| Catalogue, inventory, sales, purchasing, transfers | Yes | Yes | Yes |
| Works offline with a local store | IndexedDB | IndexedDB | SQLite |
| Queued writes replayed on reconnect | Yes | Yes | Yes |
| Sync status and retry of queued work | Yes | Yes | Yes |
| Barcode scanning | Scan field | Hardware scanner (HID and wedge) | Camera |
| Receipt printing | Browser dialog | Native and silent | System share |
| Barcode label printing | Yes | Yes | Yes |
| Installation | None (browser) | Windows installer | App build |
A RESTful API backend over PostgreSQL, a small worker for background jobs, and three clients that each keep a local cache and write queue.
The repository ships with the full documentation set. Start with the README for the system overview, then follow the installation and running guides.
Questions, bug reports, deployment help or feature requests — get in touch.