Offline-First Is a Rule, Not a Feature
Building a point-of-sale for shops on unreliable networks taught me that sync conflicts are a product decision — not something you bolt on later.
I built the point-of-sale flow for BarqiBazar, a commerce and delivery platform, for a place where the network cannot be trusted to stay up. The shop still has to take the order when the connection is gone, and it has to reconcile cleanly the moment it comes back.
That constraint changes everything. The local database — CouchDB / PouchDB in this case — becomes the source of truth the UI reads and writes, and the server becomes something the device syncs toward when it can, not something it waits on.
The hard part isn't storing data offline. It's conflicts. Two devices edit the same order while both are offline — who wins? I learned to treat that as a product question, not a technical one: some fields are last-write-wins, some merge, some need a human. Decide it deliberately, or the data decides for you.
The payoff is a POS that never freezes on a spinner and never loses a write — it behaves the same in a dead zone as it does on full bars. Offline-first isn't a feature you add. It's a rule you design around from the first table.
