What is offline-first software? How it works and when to build it

Short answer: offline-first software works fully without a network and treats the local database as the one the user talks to. Changes are saved locally at once and synchronised to a server later, when a connection is available. It matters wherever a dropped connection must not stop work: shops, restaurants, field service, warehouses, and anywhere with unreliable internet.

How is it different from "works offline"?

Many apps cache pages so you can read them offline, and then show an error when you try to save. Offline-first goes further. Every action, including writes, succeeds against local storage. The network is an optimisation for sharing data, not a requirement for the app to function.

What are the building blocks?

• Local store: SQLite on desktop and mobile, IndexedDB in browsers.
• A sync queue: each change is recorded as an operation to send when online.
• Stable identifiers generated on the client, such as UUIDs, so records created offline do not collide with each other. Time-ordered ones like UUIDv7 keep indexes friendly.
• Idempotent server endpoints: the same operation sent twice must have the same effect as once. Accept an idempotency key.
• A service worker for web apps, to cache the app shell so it loads without a network.
• Clear status in the interface: saved locally, waiting to sync, synced, failed.

How do you handle conflicts?

Two devices edit the same record offline, then both sync. Something has to decide.

• Last write wins: simple, loses data silently. Fine for low-value fields.
• Field-level merge: combine changes to different fields.
• Operation-based design: instead of syncing the final value, sync the actions. "Add 3 units" and "remove 1 unit" commute, so both apply. This is why ledger-style data is a good match. See what event sourcing is.
• CRDTs: data structures designed to merge automatically, good for collaborative text and lists, heavier to adopt.
• Ask the user when a conflict matters.

The best conflict strategy is a design where conflicts rarely happen: one till writes to one set of records, and stock changes are movements, not overwritten totals.

Where does it matter in business software?

• Restaurants: orders must be taken and sent to the kitchen even when the internet drops during a rush. I describe the design in offline-first restaurant software.
• Retail billing: a till that cannot ring up a sale is a closed shop. Prices, tax and stock must live locally.
• Field work and warehouses: staff in basements, vehicles and remote sites.

What are the pitfalls?

• Clock differences. Do not rely on device time for ordering. Use server-assigned sequence numbers, or version vectors, where it matters.
• Schema migrations on devices you cannot see. Version your sync protocol.
• Unbounded local growth. Plan what is pruned.
• Security. A device holds data. Encrypt the local store when it holds anything sensitive, and plan for lost devices.
• Silent failure. A sync queue that is stuck for days needs an alert, or someone will find out at month-end.
• Testing. Test with the network off, flaky and slow, not only on office Wi-Fi.

Should you build offline-first?

If a network failure stops work that cannot wait, yes. If users are always online at a desk, the added complexity is not worth it. Start by deciding which operations must work offline. A narrow set, such as creating a bill or an order, is far easier than "everything".