Offline-First Field Operations / 2025–Present
Beacon
Field capture, durable sync, and dispatch for disaster recovery.
In delivery · team project
My contribution
Full-stack engineer contributing to Beacon as part of a three-person team.
- 01
Capture
Work records + photos
- 02
Keep locally
Durable SQLite outbox
- 03
Sync
Retry + deduplicate
- 04
Review
QC + program reporting
Capture persists on the device. When connectivity returns, uploads retry and the server deduplicates submissions before review.
Evidence & scope
How it was built
Built collaboratively with two partners, with shared platform IP. The platform capabilities described here reflect the team’s work. Claude Code supports implementation and pre-launch review.
Available to inspect
A workflow diagram and an explanation of the outbox, retry recovery, server deduplication, and dispatch design.
Current limits
Delivery is in progress. The diagram explains the architecture; it is not a live demo. Performance and sync-test results are described in the case study; the underlying test logs are not published here.
The spark
A disaster-response contractor needed to move thousands of work orders through field crews, quality control, and program reporting, in neighborhoods where the storm had taken the cell network down with the houses. As part of the three-person Beacon team, I got to help build the system I'd always wanted to: one that treats lost connectivity as the default, not the edge case. My contributions also included negotiating and executing a five-milestone technology partnership with a national disaster-response contractor, including development funding, tiered revenue participation, and jointly owned platform IP.
The problem
Recovery crews working post-disaster zones operate where the cell network went down with the buildings. Paper work orders, lost photos, and duplicate records make program reporting slow and error-prone.
- Who it affects
- Field crews working post-disaster zones with no connectivity, dispatchers assigning thousands of work orders across subcontractor companies, and QC reviewers feeding validated work back upstream.
- Previous workflow
- Paper work orders, ad-hoc photo texting, and manual spreadsheet reconciliation between upstream program systems and what crews actually did, with duplicates and missing documentation discovered days later.
- What it costs
- Missed reimbursements from inadequate documentation, crews driving inefficient routes between scattered sites, and days of lag between field work and program reporting.
The solution
Beacon is the end-to-end field platform I help build as part of a three-person team: an offline-first React Native app with durable sync, a web QC portal, and PostGIS dispatch with clustering and route optimization.
Outcome
In delivery for a disaster-response program: offline sync engineered and tested for zero duplicate submissions, crew routing that clusters 500 sites in ~30ms, drive-time isochrone planning.
What I learned
Offline-first is a data-model decision, not a UI feature. Client-generated IDs, idempotent endpoints, and explicit sync states had to exist in the schema from day one; everything visual was easy by comparison. Adversarial AI review at scale also earned its keep: a 128-agent codebase audit caught tenant-isolation and sync bugs human review had missed.
Technical decisions
- React Native / Expo
- One codebase for Android field phones; expo-sqlite powers the offline outbox, expo-location and expo-camera the evidence capture
- MapLibre GL (web + mobile)
- Open-source maps with no per-seat licensing for crews and dispatchers
- PostgreSQL + PostGIS (Supabase)
- Work orders, missions, and operational areas as first-class geometry, with row-level security for multi-tenant isolation
- Express 5 + OpenAPI codegen
- Spec-first API: generated clients keep web, mobile, and server contracts in lockstep
- TypeScript end to end
- Shared types from database schema to mobile UI
- Claude Code
- Daily engineering co-pilot, including a 128-agent automated audit that filed 77 tracked findings during pre-launch hardening
The hard part
Designing sync you can bet a reimbursement claim on. Crews capture records, photos, and attendance in airplane-mode conditions, then sync whenever a signal appears; anything lost or duplicated becomes a compliance problem. Solved with a durable outbox: every submission gets a client-generated ID and persists locally with its photos. Uploads retry with exponential backoff (5 seconds to a 24-hour cap), an in-flight lease recovers cleanly from mid-upload crashes, and the server deduplicates on device and client IDs so retries are idempotent. The result is exactly-once delivery built from at-least-once parts.
Next steps
- QR badge check-in with label-printer support for crew attendance
- Multi-storm mission archives with cross-storm analytics
- Automated documentation packets for reimbursement submission