The default assumption in modern software development is that the device is connected to the internet. APIs are called in real time, data is fetched on demand, and offline states are treated as error conditions. This assumption breaks completely in FMCG field operations, where reps routinely visit stores in areas with no cellular coverage, unreliable network quality, or prohibitively expensive data plans. For FMCG applications to deliver value in these environments, offline capability cannot be an afterthought. It must be the foundation.
The first engineering challenge is the local database. A field rep needs access to their entire customer directory, product catalog, pricing rules, outstanding balances, order history, and route plan, all available without network access. For a mid-size distributor, this might mean 20,000 customer records, 5,000 SKUs with images and pricing, and 100,000 recent transaction records. This data must be stored in a local database on the device, indexed for fast lookup, and kept current through background synchronization.
SQLite is the workhorse for on-device storage in this context. It provides the relational query capabilities needed for complex lookups (find all customers in this territory with outstanding balances above a threshold) without the overhead of a full database server. On modern smartphones, a well-indexed SQLite database handles the data volumes typical in FMCG operations with sub-millisecond query times. The challenge is not query performance but data management: keeping the local database synchronized with the server of record.
Delta synchronization is the strategy that makes ongoing sync practical. Rather than downloading the entire dataset on each sync, the system tracks changes since the last successful sync and transfers only the modified records. A typical daily delta for a distributor with 20,000 customers might include 50-200 changed records, new customers, updated balances, price changes, and route modifications. This keeps sync fast and bandwidth-efficient, critical for devices on metered cellular connections.
The sync protocol handles the inherent complexity of bidirectional data flow. The device receives updates from the server (new customers, price changes) and sends updates back (captured orders, visit records, call logs). Conflict resolution is needed when the same record is modified on both sides between syncs. The system uses a last-writer-wins strategy for server-authoritative data (pricing, balances) and a merge strategy for user-generated data (order drafts, visit notes), ensuring that no field-captured data is lost.
Pre-loading is the initial sync that provisions a new device or re-provisions after a data reset. This is the heaviest operation, potentially transferring hundreds of megabytes of data including product images. The system handles this through chunked downloads with resume capability, so that a pre-load interrupted by network loss can continue from where it left off rather than starting over. Product images are downloaded at compressed resolution for the initial load, with full-resolution images fetched on demand when connectivity is available.
Background sync scheduling balances freshness against battery and bandwidth consumption. The system syncs when the device is on WiFi and charging (full delta sync), when cellular is available and the last sync exceeds a configurable threshold (priority delta sync covering balances and pricing only), and when the user explicitly triggers a sync before starting their route. Each sync strategy transfers different data subsets to optimize for the available conditions.
Order capture in offline mode requires careful engineering. When a rep creates an order without connectivity, the order is stored locally with a pending status. It includes all necessary data for fulfillment: customer ID, product list with quantities and prices, payment terms, and any promotional conditions. When connectivity is restored, pending orders are uploaded to the server in chronological sequence. The server validates each order against current data (credit limits, stock availability) and returns confirmation or rejection. Rejected orders are flagged on the device for the rep to review and adjust.
The progressive enhancement pattern ensures that the application provides full core functionality offline while leveraging connectivity when available. Core workflows like order capture, customer lookup, and route navigation work entirely offline. Enhanced features like real-time shelf recognition (which requires server-side GPU processing), live inventory checks, and instant payment processing activate when connectivity is available. The UI clearly indicates which features are available in the current connectivity state, setting correct expectations.
Image handling is a domain-specific challenge in FMCG. Shelf photos for recognition are typically 3-5 megabytes each. In offline mode, photos are captured and stored locally. They are uploaded for processing when bandwidth is available, with the results synced back to the device. The system queues photos intelligently, prioritizing recent captures and pausing uploads when bandwidth is constrained. This prevents a backlog of shelf photos from consuming the rep's entire data allowance.
Testing offline-first applications requires a different approach than traditional connected software. The test matrix must cover transitions between connectivity states: starting offline, going online mid-workflow, losing connection during a sync, and regaining connection with stale local data. Automated tests simulate these conditions systematically, but the most valuable testing comes from field trials in actual low-connectivity environments where the application must prove itself under real conditions.
The emerging markets where FMCG field operations are most active, across Southeast Asia, Sub-Saharan Africa, South Asia, and Latin America, are precisely the markets where connectivity is least reliable. Building offline-first is not a premium feature for these markets. It is a prerequisite for any application that expects to be used daily by field teams. The engineering investment is significant, but the alternative is building software that fails precisely when and where it is needed most.