The problem
The product gets used at physical events, where wifi is congested and mobile data is patchy. That is precisely when people need it most.
A normal fetch on render app turns into a spinner in that environment, which makes the product look broken when the thing that actually failed was the network.
What I built
- An offline first architecture on WatermelonDB. The local database is the source of truth for reads, so the UI paints instantly and never waits on the network.
- A background sync layer that reconciles local and server state once connectivity returns, including conflicts where a record changed in both places.
- Queued writes, so anything done offline is captured and replayed rather than lost without the user noticing.
- Real time updates over Socket.IO layered on top, so a connected device stays live while a disconnected one stays usable.
The hard part
Sync conflicts. Offline first is easy right up until the same record changes on the device and on the server. The work is a reconciliation strategy that resolves predictably, instead of one that silently picks a winner and loses somebody's data.
Outcome
Usable at zero bars
Full read access with no connection
Instant reads
UI paints from local DB, not the network
No lost actions
Offline writes queue and replay on reconnect
Stack
Have a similar problem?
Thirty minutes, no pitch. If this isn't the right approach for you, I'll say so.