Offline-first field sales apps in India: architecture guide from SalesUp
How to design Flutter field force apps that survive patchy 4G, sync orders reliably, and keep sales reps productive — lessons from Mobintix SalesUp deployments.
By Mobintix Team
Field sales teams in India rarely enjoy stable connectivity. Reps visit retailers in basements, industrial areas, and highways where 4G drops without warning. If your FMCG or distribution app blocks order entry until the network returns, you lose revenue and reps revert to paper notebooks within a week.
Mobintix built SalesUp — a multi-tenant field force platform — to treat offline mode as the default path, not an exception. This article explains the architecture patterns we use for offline-first mobile apps, how we reconcile conflicts when devices reconnect, and what product owners should specify before engineering starts.
Why offline-first matters for Indian field operations
Beat planning and visit compliance drive FMCG revenue, yet connectivity maps do not follow sales territories. A rep might complete twelve visits in a low-signal industrial estate, then sync everything when they reach a highway dhaba with usable data. Apps that show infinite spinners during order capture train users to distrust digital workflows.
Offline-first does not mean "no server." It means the device owns a durable local store, queues mutations, and applies server truth when possible without surprising the user. SalesUp stores catalog snapshots, pricing rules, retailer master data, and draft orders in SQLite via Drift on Flutter. Photos and GPS breadcrumbs attach to visits locally before upload workers run in the background.
Local data model design
We partition data into three tiers. **Reference data** — products, schemes, taxes — syncs on login and refreshes on a schedule or when the app receives a silent push with a version bump. **Session data** — today's beat, visit plan, attendance — expires after twenty-four hours unless pinned. **Transactional data** — orders, payments, returns — never deletes without explicit acknowledgment from the server.
Each record carries a client-generated UUID, tenant_id, updated_at, and sync_state enum (clean, pending, conflict). Server APIs accept batch uploads with idempotency keys so retries do not duplicate orders. Never use auto-increment IDs on the client — merges across devices will break.
Sync protocol overview
When connectivity returns, a sync orchestrator runs four phases: pull reference deltas since last cursor, push pending mutations ordered by dependency (visits before orders), resolve conflicts, and pull server-side assignments that arrived while offline.
Conflicts appear when a manager reassigns a beat while a rep works offline. Our rule set is explicit: server wins for master data, client wins for in-progress drafts until submitted, and visit timestamps merge with "earliest GPS wins" for compliance reporting. Product teams must document these rules — engineers should not invent them during a bug bash.
UX patterns reps actually use
Show sync status in the app bar: green when clean, amber when pending, red when conflicts need attention. Let reps continue capturing orders while uploads run — block only actions that require live credit checks. Provide a manual "sync now" button; trust matters more than invisible magic.
Compress images before enqueueing uploads. A rep photographing shelf facings should not drain data plans. Thumbnail locally, upload full resolution on Wi-Fi if settings allow.
Security offline
Encrypt SQLite at rest with keys tied to device keystore. Wipe local data on logout or after too many failed PIN attempts. Signed JWTs expire; refresh tokens require online handshake — reps re-authenticate daily. Sensitive pricing lists may use shorter TTL than catalog metadata.
Testing offline scenarios
Mobintix QA uses airplane mode scripts on Firebase Test Lab plus field days with reps carrying debug builds. Test cases include: order mid-sync interruption, clock skew across devices, duplicate SKU scans, and partial catalog updates during active visits.
Operations and observability
Server dashboards track pending queue depth per tenant, median sync latency, and conflict rate. Alert when a tenant's pending mutations exceed thresholds — often signals a bad release or regional outage.
Support teams need visibility too. Expose last successful sync time and pending mutation count in the rep profile screen so helpline staff diagnose issues without engineering escalation.
Building for low-end Android
SalesUp targets devices with 3 GB RAM and Android 10+. We cap in-memory image caches, paginate catalog queries, and lazy-load scheme rules. Performance profiling on Redmi and Samsung A-series is part of every release gate — not an optional QA step.
When not to go offline-first
Real-time fleet dispatch or live payment authorization cannot defer server truth. Hybrid models work: offline catalog and visits, online-only payments. Be explicit in contracts which features require connectivity.
Getting started on your roadmap
Audit one week of rep journeys with connectivity logging. Classify screens by tolerance for delay. Define conflict policies with sales leadership before writing sync code. Pilot with fifty users in a single city before national rollout.
Mobintix offers discovery workshops and engineering sprints for field force products. If you are planning SalesUp-style deployments or custom FMCG apps, [contact our team](/contact) for architecture review — we respond within one business day.