Build the Sync Spine Before You Build a Single Screen
Offline mode isn’t a simple add‑on; it requires a clear sync strategy. The article explains three offline levels, the cost of each, and how to decide what level your app needs. It stresses building a sync spine first and testing against real network conditions.
When a client asked for offline mode just three weeks before launch, the request seemed simple: store data on the device. The reality was more complex. Offline isn’t a feature you bolt on; it’s a decision about where the single source of truth lives. The cost of adding offline later can be orders of magnitude higher than building it in week one.
Three Levels of Offline Functionality
Offline apps can be grouped into three distinct categories, each with its own engineering footprint:
- Level 1 – Graceful Degradation: The app still needs a network for core functions but can render cached screens, preserve half‑finished forms, and recover automatically when connectivity returns. This requires a few days of careful coding but no deep architecture changes.
- Level 2 – Capture‑Now, Send‑Later: Users create work while disconnected—photos, notes, signatures—and the app queues data locally, uploading it once a connection is available. Data flows one way, eliminating conflict resolution and keeping the feature lightweight.
- Level 3 – Full Replica: The device holds a working copy of shared data, edits happen offline, and both sides must converge. This introduces conflict resolution, partial sync, schema migrations for devices that haven’t synced in months, and clock‑drift bugs. The engineering cost here is the highest.
What Determines the Cost?
Almost every project fails to specify which level it needs. The single question that shifts the budget is: Can two people change the same record while both are offline? If the answer is no—each user only creates or edits their own records—Level 2 suffices. If yes, you’re in Level 3 territory and must define conflict rules before estimating.
Other factors shape the scope:
- Worst‑case outage duration: A 90‑second loss is a retry problem; a full shift underground demands a robust architecture.
- Data size on device: The entire database rarely fits; the working set is usually a narrow slice—this week’s jobs, a region’s assets, or a set of accounts.
- Device loss or theft: Encryption, wipe paths, and retention rules must be decided early, especially for regulated data.
- Warm‑up before disconnection: The app should sync data, cache assets, and empty queues so users don’t leave with stale copies.
Conflict Resolution Strategies
When two copies of a record can change independently, you need a rule. There’s no clever default; you must pick per record type:
- Last‑write‑wins: Simple but can silently destroy work.
- Field ownership: Office owns customer addresses; field staff owns job outcomes, preventing overlap.
- Append‑only logs: Record events instead of states; two devices appending never conflict.
- Human review queue: For collisions your rules can’t settle, a named person resolves them.
The guiding principle is never to discard user data silently. If the app can’t merge, it should preserve the data and alert someone.
Practical Steps for Scoping Offline Features
1. Observe real work: where people stand, how long they stay, and how they use paper when the app fails. 2. Name the offline level for each feature, not for the whole app. 3. Define the working set: what lands on the device, how it refreshes, and which records need conflict rules. 4. Build a sync spine: a single record type that moves through the entire sync flow, tested against flaky networks before any screens exist. 5. Deploy to a real dead zone—e.g., a depot basement—to surface issues that simulators miss.
Many projects falter because the sync layer is built after screens are already in place. By front‑loading the sync spine, you avoid costly rewrites and ensure the app behaves correctly where work actually happens.
When Offline‑First Is a Bad Fit
Offline‑first is unsuitable for scenarios where the data must be authoritative at the moment of action—payments, stock allocation, or any operation that could create duplicate records if two devices write simultaneously. In such cases, a server‑centric architecture with real‑time collaboration is required.
Designing from the user’s environment—like a ride‑sharing app that verifies riders at motorway junctions—ensures the software meets real needs rather than office expectations.
In short, offline mode is not about surviving a rare outage; it’s about building for the places and conditions where users actually work.
Why it matters
Understanding the true cost and scope of offline functionality prevents costly rework and ensures the app remains reliable in the field.
Key points
- Offline mode requires a clear sync strategy, not a bolt‑on feature.
- Three offline levels exist: graceful degradation, capture‑now‑send‑later, and full replica.
- The key cost driver is whether multiple users can edit the same record offline.
- Conflict resolution must be defined per record type, not globally.
- Building a sync spine before screens avoids later project derailment.
- Offline‑first is unsuitable for authoritative real‑time data like payments.
- Design from real user environments yields more effective solutions.
Frequently asked questions
What is a sync spine?
A sync spine is a single record type that is fully tested through the entire sync flow—capturing, queuing, uploading, and reconciling—before any UI screens are built.
How do I decide which offline level my app needs?
Ask if two users can edit the same record while disconnected. If yes, you’re at Level 3; if not, Level 2 or Level 1 may suffice.
Why is conflict resolution important?
Without proper rules, data from different devices can overwrite each other, leading to lost work or inconsistent state.
