Most business software breaks the moment connectivity drops. For teams working in warehouses, field sites, or anywhere with spotty cellular, that's not an edge case — it's the job. Here's how to build software that handles it.
A maintenance technician walks into a processing facility to complete an inspection. They open the app. It spins. No connection. They switch to paper, finish the job, and spend 45 minutes re-entering data back at the office. The software that was supposed to save time created more of it.
This is the normal outcome when business software is built with the assumption that internet connectivity is always available. That assumption holds in a downtown office. It does not hold inside large metal structures that block RF signals, at remote job sites that depend on variable cellular coverage, in underground infrastructure, or in facilities where IT policy restricts wireless access to protect control systems. These are exactly the environments where field teams do their work, and they are exactly the environments where standard software stops functioning.
The fix is not better cell coverage. It is designing the software differently from the start: the device holds the data, the device does the work, and connectivity is used to sync results when it's available rather than required to do anything at all. This approach is called offline-first, and the gap between how most software is built and how offline-first software is built is what this post covers.
The Difference Between Offline-Capable and Offline-First
Offline-capable software handles network loss gracefully: it catches API errors, shows a "no connection" message, and resumes when the network returns. The user cannot do meaningful work during the outage.
Offline-first software is designed so that the primary work loop, the operations a field technician performs hour to hour, functions entirely without network access. The local device has the data the technician needs: their assigned work orders, the asset records they'll be inspecting, the forms they'll fill out, reference documentation they'll consult. When network connectivity is available, the device synchronizes with the server. When it isn't, the technician doesn't notice.
This distinction changes the architecture at the storage layer. Offline-capable software reads from the server and shows what it gets. Offline-first software reads from a local store that is kept synchronized with the server when connectivity permits.
The local storage layer for mobile applications is typically SQLite, accessed either directly or through an ORM like Realm or via a library like WatermelonDB that provides a reactive query layer over SQLite. For progressive web apps, IndexedDB is the browser's native persistent storage and handles structured data adequately for most field application use cases. The choice between a native mobile app and a PWA matters here: native apps have better access to device hardware (camera, GPS, NFC, Bluetooth), but PWAs eliminate the app store deployment cycle and are simpler to distribute to teams that change devices frequently.
The Sync Problem: Where Most Implementations Fall Apart
Storing data locally is the easy part. The hard part is synchronization: how do changes made on the device get merged with changes that happened on the server while the device was offline, and how are conflicts resolved when both sides changed the same record?
The failure mode in naive implementations is last-write-wins: whichever side synced most recently overwrites the other. This works when only one user ever touches a record at a time. It fails silently when a supervisor updates a work order on the server while the assigned technician is updating it offline. The sync resolves in favor of whoever synced last, and the other party's changes disappear without any indication that a conflict occurred.
The approaches to conflict resolution form a spectrum from simple to correct:
Timestamp-based conflict detection with manual resolution. Every record carries a last_modified timestamp. When a device syncs, the server compares the device's timestamp against its own. If both sides modified the record since the last sync, the server flags the conflict and presents both versions to a user or administrator for resolution. This is correct but requires user intervention for every conflict, which becomes impractical at volume.
Operational transformation. Instead of syncing record states, the device syncs operations: "field X was set to value Y at time T by user U." The server applies operations in causal order, which allows concurrent edits to different fields of the same record to be merged automatically. Conflicts only arise when the same field was edited by two parties concurrently, which is less common than record-level conflicts. This approach is the basis of systems like Google Docs and is the right design for collaborative editing of structured records.
CRDTs (Conflict-free Replicated Data Types). A CRDT is a data structure designed so that any two copies of the data can always be merged to produce a consistent result, regardless of the order operations were applied. For simple operations like counters, append-only lists, and last-write-wins registers, CRDTs provide automatic conflict resolution without the overhead of manual resolution or operational transformation. The tradeoff is that not all data types map cleanly to CRDT semantics, and implementing custom CRDTs for complex domain models requires careful design.
For most field operations software, the practical architecture is a combination: operational transform for high-contention fields (status, assignment, completion flags), and simple field-level last-write-wins with conflict logging for lower-contention fields (notes, measurements, attachments). The conflict log provides an audit trail for cases where data integrity questions arise later without requiring manual resolution of every detected conflict.
Schema Design for Sync
The local schema and the server schema don't need to be identical, but they need a consistent identity model. Every record needs a stable, globally unique identifier that is assigned at creation time on the device, before the record has been synchronized. Using server-assigned sequential integer IDs creates a bootstrapping problem: the device can't create a work order record and link child records to it until the parent record has been synced and the server has assigned an ID.
The solution is client-generated UUIDs assigned at record creation time. The device generates a UUID for a new work order record, links all child records to that UUID immediately, and syncs them all as a unit. The server accepts the client-generated UUID as the record's permanent identifier. This eliminates the create-then-sync-to-get-ID dependency chain and allows the device to create arbitrarily deep record hierarchies offline.
A sync state field on each record tracks its synchronization status: synced, pending_create, pending_update, pending_delete. The sync engine processes records by status: sending pending creates and updates to the server, processing server-side deletes for records the device holds, and marking records synced on successful acknowledgment from the server.
Deleted records are a special case. Hard deletes, removing the row from the local database, create a gap in the audit trail and make it impossible to detect when a server-side delete should propagate to the device. Soft deletes, a deleted_at timestamp field, allow the sync engine to propagate deletions as state changes rather than record absences, which is far more reliable.
Handling Attachments: The Bandwidth Problem
Field inspection software almost always involves photos. A technician photographs a defect, an equipment state, or a completed installation. These attachments are the most bandwidth-intensive part of the sync and the most likely to fail mid-transfer.
The architecture for attachment sync is independent of record sync. Attachments are stored locally as files with a reference in the database record. The sync engine uploads attachments separately from record data, using a resumable upload protocol that can recover from interrupted connections without restarting from zero.
This matters in field environments because connections drop mid-transfer at high frequency. A 5MB photo that requires a 5MB uninterrupted transfer to complete will frequently fail in environments with spotty cellular coverage. A resumable upload protocol (Google's resumable upload API and AWS S3's multipart upload both support this) can resume from where it left off after an interruption, which dramatically improves success rates in degraded network conditions.
Attachment uploads should be queued and processed in the background, independently of the user's interaction with the app. The user submits a form with a photo attachment, the form data is written to the local database and marked pending, and the background sync engine handles the upload when connectivity permits. From the user's perspective, the submission succeeded immediately. The sync happens asynchronously.
Compressing photos on the device before upload is almost always worth doing. A raw 12MP photo from a modern phone is 8 to 15MB. Compressed to 80% JPEG quality at a maximum dimension of 1920px, it's typically under 500KB with no meaningful loss of inspection-relevant detail. At scale, this is the difference between a sync queue that clears in five minutes on a cellular connection and one that takes an hour.
Security in Offline-First Systems
The security model for offline-first software is different from server-side security because the data is on the device. A server-side system controls data access at the API layer: a user can only query records they're authorized to see. An offline-first system pushes data to the device in advance, so the access control boundary moves to the sync protocol: the server only sends records to a device that the authenticated user is authorized to access.
This has practical implications. A technician should receive work orders assigned to them, reference documentation for the assets they'll be inspecting, and form templates for the inspections they'll perform. They should not receive unrelated work orders assigned to other teams, or records from facilities they don't work at. The sync query on the server side must enforce these boundaries, because once the data is on the device, it can be read by anyone who has access to the device's filesystem.
Device encryption (enabled by default on modern iOS and Android) protects local data at rest. Application-level encryption of the local database provides a defense-in-depth layer for sensitive data, at the cost of additional implementation complexity and a key management requirement. For most field operations applications, relying on device-level encryption and strict sync-side access control is sufficient.
Authentication tokens stored on the device for offline access need an expiration and rotation mechanism. A long-lived token is convenient for field use but creates a security problem if a device is lost or compromised. The practical solution is a token with a moderately long expiration (30 to 90 days is typical for enterprise mobile apps) combined with a device management system that can remotely revoke tokens for specific devices. For high-security environments, shorter token lifetimes with silent background refresh when connectivity is available balance security with field usability.
Designing the Sync Engine
The sync engine is the component that runs in the background, processes the pending queue, and reconciles local state with server state. Its design has more impact on system reliability than any other component.
The sync engine needs to handle four scenarios reliably:
Network unavailable. The engine detects that no connectivity is available, skips the sync cycle, and schedules a retry when connectivity is restored. The retry should be triggered by OS-level network availability events (iOS Network Framework, Android ConnectivityManager) rather than polling, because polling on a mobile device consumes battery continuously even when no connectivity is present.
Partial sync completion. The sync starts, uploads several records successfully, and the connection drops before completing. The engine needs to resume from where it left off on the next attempt, not restart from the beginning. This requires idempotent server endpoints (sending the same create request twice produces the same result as sending it once) and tracking which records in the pending queue have been successfully acknowledged by the server.
Server-side conflict. The server rejects a record update because it conflicts with a server-side change. The engine needs to apply the conflict resolution strategy, update the local record accordingly, and report the conflict to the user if manual resolution is required.
Schema migration. The app is updated with a new version that changes the local database schema. The migration needs to run successfully before the sync engine starts, and it needs to handle cases where the device has pending changes that need to be preserved through the migration.
Background sync on mobile is constrained by OS-level restrictions on background execution. iOS Background App Refresh limits background execution to periodic windows controlled by the OS, not the app. Android's WorkManager API provides a more flexible background task scheduling system but still has battery-optimization restrictions that affect scheduling. Field apps that need frequent sync (every few minutes when connectivity is available) need to handle the case where background sync is rate-limited, by syncing aggressively when the app is in the foreground and accepting less frequent background sync as the constraint rather than a bug.
What This Looks Like in Practice
A well-designed offline-first field application for an inspection workflow looks like this to the end user: the technician opens the app in the morning, reviews their assigned work orders for the day (already loaded on the device), and drives to the first site. At the site, they work through the inspection form, attach photos, and mark defects. They submit the inspection. The app shows a success state. Behind the scenes, the submission was written to the local database with a pending_create status. The sync engine queues it.
When the technician drives out of the facility to their next site and their phone reconnects to cellular, the sync engine uploads the inspection record, waits for acknowledgment, uploads the photo attachments via the resumable upload endpoint, and marks the records synced. The server processes the submission, runs any server-side validation, and makes the completed inspection visible to the manager reviewing submissions back at the office.
The technician never interacted with the sync. From their perspective, the app worked. From the manager's perspective, the inspection appeared in the system shortly after it was completed. The network gap in the middle was handled automatically.
Building software that works this way isn't dramatically more complex than building software that assumes connectivity. It requires a different storage model, a sync engine, and careful attention to conflict resolution and attachment handling. The investment is front-loaded. The return is a tool that field teams actually use, because it works in the conditions they work in.
Field software that shows error screens in the field gets worked around. Inspection records go back to paper. Photo documentation gets texted to a group chat. The formal system becomes a secondary data entry exercise done back at the office from notes. The offline-first architecture is what prevents that outcome.