Offline-First Point of Sale Web App for Multi-Till Retail Shops

The problem shops have when the internet or power goes

A busy grocery store, bakery or pharmacy with two or three tills cannot stop selling because the internet dropped or the router lost power. In many cities that happens daily. Cloud POS systems either stop working, or run in a reduced offline mode where some features are disabled and tills cannot see each other's sales. When they reconnect, stock can go negative, receipt numbers clash, and the evening report does not match the cash drawer. Many owners respond by going back to a desktop POS on one machine, which loses everything cloud gives them.

What already exists and the gap

• Loyverse POS allows sales offline, but refunds are disabled, customer records cannot be created or edited, open tickets do not sync between devices, and integrated card terminals do not work until the connection returns.
• Square supports offline card payments with configurable limits and a list of payment types that are not available offline.
• Odoo POS runs in the browser and can continue offline for a while, within the wider Odoo ERP.

The gap is a POS designed local-first from day one: every till is fully functional offline, tills converge correctly when reconnected, and the system can prove it. That is a hard engineering problem, and exactly the kind of thing that makes an FYP stand out.

What you build

Roles: cashier (till), shop manager (back office, conflicts, end of day), owner (reports).

Each till is an installable web app with a local database. Sales, returns and cash events are appended to a local operation log. When a connection exists, tills push their log and pull changes (prices, products, other tills' stock effects) from the server. The back office sees near-live data when online, and eventually-consistent data after outages.

The technically interesting part

Designing data so it merges. Stock quantity cannot be a single number that each till overwrites. Model it as movements (the server sums them) or as a counter that supports increments and decrements from many replicas. Prices are last-writer-wins by server timestamp, but a sale records the price it used, so history never changes.

Sync protocol. Each till has an ID and a monotonic sequence number per operation. The server acknowledges the highest contiguous sequence it has stored; the till retries the rest. Operations are idempotent by (till, sequence). This is the same pattern many local-first tools and mobile sync engines use, and it is simple enough to reason about and test.

Receipt numbering offline. Use a per-till prefix plus a local counter, so numbers stay unique without coordination and gap-free per till, which suits auditors.

Testing under failure. Build a test harness that runs several simulated tills, randomly cuts the network, restarts browsers and replays operations, then checks invariants: every sale is counted once, stock equals receipts minus sales, and every till eventually agrees with the server.

How to evaluate it

• Convergence: in 100 randomised chaos runs with 3 tills and 1,000 operations each, report how many converged with all invariants intact (target 100).
• Time to converge: after a one-hour offline period with 500 sales per till, measure sync time on a typical mobile data connection.
• Checkout speed: time for a 10-item sale offline versus online with 5 cashiers; the offline path should be no slower.
• Field test: run one real shop for at least a week and record outages, operations synced and any conflicts the manager had to resolve.

Suggested plan

1. Weeks 1 to 3: observe a shop's tills during a power cut; read about local-first design and write the data model.
2. Weeks 4 to 8: till UI with local database, catalogue caching, receipts.
3. Weeks 9 to 13: operation log, sync server and acknowledgements.
4. Semester 2, weeks 1 to 4: stock merge model, receipt numbering, conflict report.
5. Weeks 5 to 9: chaos test harness, back office, end of day.
6. Weeks 10 to 14: field test and report.

Path to a product

Your first customer is a two or three till shop that already suffers outages, such as a bakery or grocery on a busy street. Charge per till per month, with the back office included. Retail associations and wholesale distributors that supply many small shops are the scaling channel.

Scope warning

Do not integrate card terminals or wallets; record the payment method. Do not build accounting, loyalty, e-commerce or delivery. Do not attempt a general CRDT library; design the few data types you need and test them hard.

Learn what you need on Sefism

• System design roadmap : replication, consistency and conflict handling explained step by step.
• Frontend cheat sheet : service workers, caching and state for an installable web app.
• Patterns.dev : rendering and loading patterns for a fast till interface.
• All Things Distributed : Werner Vogels on eventual consistency and designing for failure.
• Shopify Engineering : retail and point of sale engineering at scale.

Get help with this idea

Get the data model reviewed before you write the sync code. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session