Mobile system
A field app that captures work away from the office
Work happens on site and gets recorded on paper. The paper reaches the office days later and someone retypes it. Invoicing waits, and disputes come down to handwriting.
Constraints that usually apply
- Signal is unreliable, so capture has to be fully offline with a visible sync state
- Devices are personal or shared, which changes how sessions and data retention work
- Users are outdoors and often gloved: large targets, high contrast, few taps
- Photos and signatures make payload size a real design consideration
Stack
Architecture
- Flutter application with a local SQLite store as the primary write target
- Sync queue with idempotent uploads, retry and conflict rules decided in advance
- Image compression on device before upload
- Backend API that accepts batches and reports per-record outcomes
- Push notifications for job assignment and sync failures
Illustrative interface, drawn to show the screens involved
A realistic build timeline
- Weeks 1–2
Device and connectivity survey, offline model, the one core capture flow prototyped.
- Weeks 3–6
Capture, queue and sync built and tested on throttled and offline networks.
- Weeks 7–9
Job assignment, office-side views, notifications, hardware testing.
- Weeks 10–11
Store submission, pilot with one team, paper kept as fallback.
Indicative only. Real dates come out of discovery, and they move when your side is short of time as often as when ours is.
What you own at handover
All of it, and from day one rather than at the end. If you replaced us mid-project you would lose momentum, not assets.
- Repository and build pipeline for both stores
- Store accounts, certificates and provisioning in your name
- Offline and conflict-resolution rules documented
- Crash and performance monitoring dashboards
Is this a real project? It is the kind of system we build. Here is exactly how we would approach yours.