The construction-site mobile app is one of the trickiest problems in African software. The user is a foreman, three hours into a 12-hour day, holding a four-year-old Android in dust and direct sun. Connectivity is intermittent. The work being done has to flow into finance, procurement, and an executive dashboard before anyone trusts the numbers.
Most apps fail on day one because the architecture team treated "offline mode" as a feature rather than the foundation. This is what we've learned shipping it as the foundation.
Why naive sync always breaks
The naive pattern: app shows server data when online, queues writes when offline, replays them when connection returns. It works in the demo and the early-stage pilot. It breaks the moment two foremen edit the same record on different sites with patchy reception.
Construction-site reality includes: multi-day disconnections, multiple users editing the same project simultaneously, photos and videos taken offline that need to upload reliably, supervisors moving between sites with different signal strengths. The naive sync queue can't handle any of these well.
Local-first architecture and CRDTs
The architectural shift is to treat the local copy as the source of truth and treat the server as the eventually-consistent replica. CRDTs (Conflict-free Replicated Data Types) make this provably safe — concurrent edits merge deterministically without operator intervention.
Practical implementation: the mobile app writes to a local SQLite database immediately on user action; a background worker syncs deltas to the server when connectivity allows; the server applies CRDT merge logic and broadcasts deltas to other clients. The user sees their change instantly, regardless of network state.
Augusta's CRDT toolkit, used in the Hampton Construction app, handles three CRDT types: register (last-write-wins for simple fields), set (additions and removals to a list), and counter (numeric aggregates). 95% of construction-app data fits into one of those three.
The day we moved from queue-and-replay to local-first CRDT was the day Hampton's foremen stopped logging support tickets. The architecture went from being a constant source of anxiety to invisible infrastructure.— Patrick Wakasiaka
UX patterns that work on a real site
- Show the connection state, but don't gate the work. A discreet indicator at the top of the screen says "online / syncing / offline (will sync later)." User keeps working regardless.
- Big tap targets. Foremen wear gloves. Bottom-sheet bottom-aligned actions; minimum 56pt tap targets.
- High-contrast in sunlight. Test the design in actual direct sun. Most "designed in Figma" UIs are illegible at noon.
- Photo capture by default. Construction documentation is mostly photographic. Camera-first flows beat form-first flows.
- Sync on Wi-Fi only by default for media. Foremen don't want their data bundle eaten by a 12MB inspection photo.
Field realities the demo doesn't show
Test on the actual device family your users have. An Android 8 phone with 2GB RAM behaves nothing like the iPhone the dev team uses. If the app doesn't work on the cheap phone, it doesn't work.
Other realities the design team needs to internalise:
- Battery dies. Sync should resume gracefully when the phone comes back on.
- Phones get lost or stolen. Authentication should be re-claimable from another device without losing offline-queued data.
- Workers turnover monthly. Onboarding has to be self-service and fast.
- Procurement managers want a desktop view of the same data — design the desktop and mobile experiences as one product.
Building yours
Offline-first isn't a checkbox feature; it's a foundational architectural choice that touches data modelling, networking, UX, and operations. The teams that succeed are the ones that commit to it from sprint zero rather than retrofit it after the pilot.
If you're scoping a construction or field-services mobile app, we're happy to share the patterns we use. The code we wrote for Hampton is now an internal package we deploy on every offline-first project.