Most "offline-first" advice assumes your users lose signal occasionally. In practice, across the markets I build for, signal is the exception, not the rule — and that changes almost every architectural decision you'd otherwise default to.
The instinct is to cache reads first because that's where the user-facing lag shows up immediately. But the write path — what happens when someone submits a form with no connectivity at all — is where trust gets won or lost.
If a write silently fails and the user finds out three days later, you haven't built an offline app. You've built a data-loss machine with a nice UI.
This is where a local-first database like WatermelonDB earns its complexity. Every mutation gets written locally first, queued, and synced opportunistically — the user never waits on the network to see their own action reflected.
When two devices edit the same record offline and reconnect, "last write wins" is the easy technical answer and often the wrong product one. For most of the apps I've shipped, the right call has been to surface the conflict to a human rather than silently resolve it.