An offline-first field app with Flutter and SQLite

The scenario

Imagine a field team recording equipment inspections in places with unreliable connectivity. People need to finish a checklist, attach a photograph, and see which work is saved locally. The reference product would make offline work an explicit state and synchronize it later, rather than treating every network failure as a failed inspection.

Commit useful work locally

The application repository would expose local records to the interface and coordinate the remote service. Creating or editing an inspection would save its local state and a pending operation in one SQLite transaction. A stable client-generated operation ID would survive application restarts.

The interface would distinguish saved on this device, waiting to sync, synchronized, and needs review. Photographs would have their own upload state and checksums, rather than making the entire record disappear when one large attachment fails. Local storage limits and account logout would have deliberate handling.

Define what the server acknowledges

FastAPI could expose a synchronization contract containing the operation identity, record version, and intended change. A repeated request would return the existing outcome when appropriate. The client would remove an operation from its queue only after receiving a durable acknowledgement.

Conflicts would be part of the contract. If another person changed the same record, the service could reject a stale version and return the current one for review. Automatically choosing the latest arrival would be inappropriate for fields where one person’s work must not overwrite another’s.

Assume background execution can stop

The sync worker would retry bounded batches when execution and connectivity allow. Mobile operating systems can suspend work, so foreground reconciliation would remain available. The worker would resume from durable queue state instead of assuming a background task ran to completion.

Tests would switch connectivity during upload, terminate the application between server commit and acknowledgement, and reconnect with an expired session. A small sync-status view would help a person understand outstanding work and resolve conflicts without manually deleting local data.

What to validate

• An inspection survives an application restart without a network.
• A repeated operation does not create a second server record.
• Attachment and record states remain understandable after interruption.
• Concurrent edits follow a visible conflict policy.

The tradeoff

Offline support adds data lifecycle and conflict decisions to the product. Begin with the workflows that genuinely need local operation, and keep actions requiring current server state explicitly online.