Offline-First Apps and Sync Conflicts: The Hard Problem Nobody Mentions

"Make it work offline" is a reasonable, common request, and it hides a genuinely hard problem underneath the simple phrasing: what happens when the same piece of data gets changed on two different devices while both were offline, and they both try to sync their version once connectivity returns?

Why this is harder than it sounds

A single-device app with no offline mode never has to answer this question — there's only ever one current version of the data. The moment offline editing is allowed across multiple devices or by multiple people, conflicting edits become not just possible but inevitable, and the app needs a real, deliberate answer for what happens next.

The strategies that actually exist

• Last-write-wins — simplest to implement, and it silently discards one person's changes, which is fine for low-stakes data and genuinely bad for anything important.
• Merge strategies — combining non-conflicting changes automatically, and surfacing genuine conflicts for a human to resolve, which is more work to build and far more trustworthy.
• Field-level conflict resolution, tracking changes at a granular level so two edits to different fields on the same record don't need to conflict at all.
• Explicit conflict UI — showing the user both versions and letting them choose, which is the most transparent option and requires the most design thought to not feel confusing.

Why this deserves attention before launch, not after

This is exactly the kind of decision that's expensive to retrofit — the data model and sync logic both need to be built around the chosen conflict strategy from the start, similar to the offline requirements we described for field service software.

Offline mode isn't just 'the app still works without internet.' It's a promise about what happens to someone's work when two versions of reality need to become one again.

We push clients to decide on this strategy explicitly and early, matched to how serious the consequences of a lost edit actually are for their specific use case — not as a technical afterthought discovered during testing.