Building Offline-First Mobile Apps for Field Sales Teams: What Actually Works
A field sales rep in Faisalabad walks into a wholesale market at 9:47 AM. His phone has one bar. By 10:15 he's taken orders from six shops, updated stock counts, and photographed a merchandising display. His app never once showed a loading spinner.
That's the bar. And most B2B mobile apps still can't clear it.
I've spent the last few years watching what happens when SaaS built for coffee-shop Wi-Fi meets the reality of field sales in emerging markets. It's ugly. Reps stop using the app. Managers stop trusting the data. The whole route to market for FMCG breaks down because someone assumed 4G would just… work.
Here's the thing — offline-first isn't a feature. It's an architectural decision you make on day one, or you rebuild everything on day 400. I've seen both. The second one is expensive.
The mental model most teams get wrong
Most engineers think about offline mode as a fallback. Network fails, cache the request, retry later. That works for a photo upload. It doesn't work for a rep taking 40 orders across a beat, each one dependent on live inventory, credit limits, and pricing rules that change per outlet.
Offline-first flips the assumption. The local database is the source of truth for the session. The server is eventually consistent with the phone, not the other way around. Every read hits the local store instantly. Every write is queued, versioned, and reconciled when connectivity returns.
I got this wrong at first. Built the first version of a field app assuming we'd sync every 15 minutes. Reps in low-signal markets would open the app and wait. And wait. Then close it and write orders in a notebook. All that engineering — bypassed by a pen.
The rebuild used what I'd now call the standard offline first mobile app architecture: SQLite on device, a sync engine with conflict resolution, and a UI layer that literally doesn't know or care if the network exists. The rep opens the app. It works. Sync happens in the background, silently, whenever a signal shows up.
What good low connectivity mobile app design actually looks like
A few principles I've watched teams learn the hard way:
Bundle the catalog. Don't fetch SKUs on demand. A distributor might carry 800 products. Download them all at login, keep them local, delta-sync changes. Storage is cheap. A rep waiting for a product search to load over EDGE is not.
Queue everything, including reads that matter. If a rep queries a shop's credit balance and the network's down, don't error out. Return the last known value with a timestamp: "as of yesterday 6 PM." Reps can make decisions with stale data. They can't make decisions with a spinner.
Design for interrupted sessions. The phone dies. The rep gets on a bus. The app gets backgrounded for two hours. Every state — half-finished order, unsaved note, in-progress photo capture — needs to survive. Persist to disk on every meaningful state change, not just on submit.
Make sync visible but not annoying. A small badge showing "3 orders pending sync" builds trust. A popup every 30 seconds saying "syncing…" destroys it.
Platforms like Zivni — which builds field sales management software for FMCG teams across South Asia and Africa — have basically had to make this their entire engineering philosophy. When your users are booking orders in markets where 3G is a luxury, offline-first isn't a nice-to-have. It's the product.
Conflict resolution is where most projects die
Two reps update the same outlet's contact number from different phones, both offline, three hours apart. What happens when they both sync?
Honestly, this is the boring hard problem nobody wants to talk about. Last-write-wins is the easy answer and it's usually wrong. Reps overwrite each other's work. Managers lose data. Trust erodes.
What's worked in practice:
- Immutable transaction logs. Orders, visits, and stock counts aren't rows you update. They're events you append. You can replay them, audit them, and never lose one to a merge conflict.
- Field-level merges for mutable entities. For things like customer records, sync field-by-field with timestamps. If Rep A updated the phone number at 10:03 and Rep B updated the address at 10:47, both changes survive.
- Explicit conflict UI for the ambiguous cases. When you truly can't decide, ask a human. But make it rare — maybe one in 500 syncs. If you're asking every day, your model's broken.
The tricky part is that FMCG data has weird business rules. A rep can't book an order that exceeds credit limit. But credit limit is calculated on the server, from outstanding invoices that only the server knows about. So do you block the order offline? Allow it and reject on sync? Show a warning based on the last known limit?
We settled on: allow with warning, flag for supervisor review on sync. Reps hated being blocked more than they hated occasional rejections. Your mileage may vary — this is a business decision dressed up as a technical one.
Things I'd tell my past self
Ship the sync engine before you ship the features. If sync is bolted on later, it will never really work. It has to be the skeleton, not the skin.
Test on cheap Android phones with 2GB RAM in airplane mode. Not on your iPhone 15 Pro on office Wi-Fi. The gap between those two experiences is roughly the gap between a product that gets used and one that gets uninstalled.
Instrument everything. How long between order entry and successful sync? What's the p95? How often do reps force-close the app mid-sync? You need this data or you're guessing.
And measure the business outcome, not the technical one. The best route to market for FMCG isn't the one with the fanciest app — it's the one where reps actually record what happened in the market, on the day it happened, without cheating the system. If your app is designed well enough that reps trust it in a basement in Lahore with no signal, you've probably built something worth using.
What's the hardest part of your current field ops stack — is it the tech, or the humans using it?