Field staff apps (delivery riders, sales reps, technicians) spend a lot of time with poor or no connectivity. If the app assumes a network, staff stop trusting it and go back to paper. These are the five decisions we now make on day one when building this kind of app.
1. Treat the local database as the source of truth
The UI reads and writes only to the on-device database (SQLite through drift, or Isar). The network is a background sync concern, not something a screen waits on. This one rule removes most "spinner forever" bugs.
2. Give every record a client-generated ID
Use UUIDs created on the device, not auto-increment IDs from the server. A record created offline then needs no ID remapping when it syncs, and related records (an order and its line items) can be created together without a round trip.
3. Queue changes, don't sync tables
Store each change as an entry in an outbox table: what changed, when and by whom. A background worker pushes the queue in order when the connection returns, and marks entries done only after the server confirms. Retrying a queue is far easier to reason about than diffing whole tables.
4. Decide conflict rules before you write code
Two people editing the same customer offline will happen. Pick a rule per entity: last write wins for notes, server wins for prices and stock, and "flag for review" for anything involving money. Write these rules down where the whole team can see them.
5. Show sync state honestly
A small indicator such as "3 changes waiting to sync" does more for trust than any amount of polish. Staff need to know whether the office can see what they just entered.
None of this is specific to Flutter, but a single codebase makes it practical to get it right once for both Android and iOS. If you are planning an app like this for your own team, the mobile app development team at Jantrah Tech works on exactly these problems.
Top comments (0)