Offline-first field inspection app for an Australian state government agency

The challenge

An Australian state government agency runs a regulatory inspection programme across its jurisdiction. Its inspectors work on site, in buildings where mobile coverage is unreliable or absent. The data they capture supports regulatory decisions, so it has to be complete and attributable.

The field application therefore has to work with no connection at all, then reconcile cleanly against the Salesforce platform that holds the regulatory record. The inherited build carried the field workflow, and the agency asked us to take the reconciliation layer and the interface to the standard the programme now needs.

We ran a code-level audit alongside field observation and user feedback, and used it to scope the work. The result was a single modernisation programme covering the sync backbone and the interface together.

What we built

The production application is a React Native app for iOS and Android, built around the Salesforce Mobile SDK with a SmartStore offline database and custom Apex REST services. It covers the field workflow: a building audit wizard, hazard records across several material types, sampling, removal and immediate-action flows, clearance certification, map and camera capture, and a QR code and Bluetooth printing flow. It has run in production for several years on a numbered release train, with Firebase used for crash reporting, performance traces, remote feature flags and forced version upgrades.

The 2026 modernisation programme rebuilds the sync backbone and the interface together. The following are built and in acceptance testing, not yet released to the field:

• Parallel, incremental sync. Record types sync concurrently, and each type carries a last-sync watermark, so a cycle pulls deltas rather than the full data set.
• A durable upload outbox. The queue is persisted, survives app close, uploads in parallel with streaming and compression, and retries each item independently.
• Conflict detection. Timestamp-based detection preserves both versions and surfaces the clash in a read-only Issues tab for out-of-band resolution.
• Backend-assisted sync. A dedicated Salesforce delta endpoint and indexes on hot fields, with a fallback path, designed with the platform team that owns the same client’s Salesforce environment.
• Sync made visible. An always-present status pill with nine sub-states, a sync sheet with queue and issues grouped by record type, an offline banner showing pending change counts, a staged pull indicator, and a last-synced label that triggers a sync on tap.
• A single design system. Six semantic tones across text, background and ring slots, a six-step type scale, all pairs verified at 4.5:1 or better, WCAG 2.1 AA calibrated for bright outdoor screens, 44 point touch targets and reduced-motion fallbacks. It is documented in a component gallery.
• Instrumentation. Performance and crash reporting traces on the sync path, so behaviour in the field is measurable.

How we worked

The programme was scoped before it was proposed. We reviewed the running app, analysed the source, produced an architecture position and an effort model, then issued two proposals: a targeted sync fix, and a broader modernisation that merged the sync work with the interface rebuild. The second was approved and became the delivery plan.

Scope is 13 epics, 55 stories and 12 test items, run over eight sprints across seven stages. The programme was costed and staffed on a team of three developers, two testers, a business analyst and a project manager. Each epic has a written solution design, and the ticket backlog was generated from the epic plan and those designs rather than assembled ad hoc.

Rollout safety is a design constraint. Every screen sits behind its own remote feature flag, with old and new coexisting for an extended transition period and a remote kill switch on each. Every stage ships as an independently releasable build, gated by code review, QA on both platforms with parity checks, technical lead sign-off, then a pilot with a small panel of practising inspectors. No stage requires a big-bang cut-over.

Production support ran in parallel throughout. The live application kept shipping releases on its normal cadence while the redesign was developed alongside it.

Outcomes

The modernisation is in system and user acceptance testing as at September 2026. It is not live to the field. The items below are capabilities built and under test, not measured results.

• Parallel, incremental sync. Record types sync concurrently, each carrying its own watermark, so the app pulls deltas rather than the full data set.
• Uploads that survive the app closing. A persisted upload outbox with per-item retry.
• Conflict detection with both versions preserved. Timestamp-based detection, with the clash surfaced for out-of-band resolution.
• Sync state made visible to the user. Nine explicit sync sub-states, a queue and issues view, and an offline banner with pending change counts.
• Sync behaviour made measurable. Performance traces and crash reporting on the sync path.
• One design language across the application. A semantic token system with verified contrast ratios, outdoor-legible colour and 44 point touch targets.
• Targets set for the programme. Full sync under 30 seconds, incremental sync under 10 seconds, and a sync failure rate under 2 per cent. These are targets. Measured results will come from acceptance testing and the field pilots.
• Continuity of service through the rebuild. The production application stayed on its release train, with per-screen flags and staged releases, so no stage requires a cut-over.

Measured post-release performance, user numbers and audit volumes are not published here. They are pending client confirmation and release of the completed programme.