All work
ConceptAn internal prototype we use to test an approach. Not deployed for a client.

Offline-first app for people who work in basements

A field app that behaves the same with no signal, and syncs without asking the technician to think about it.

Area
Mobile apps and connected machines
Written
2026
Built with
  • React Native
  • SQLite
  • TypeScript
  • Node.js
A narrow service tunnel lined on both sides with large insulated heating pipes, running away from the camera.
Inside this project

The problem

Field technicians work in plant rooms, lift shafts and warehouses — the exact places mobile data does not reach. Most field apps are a thin shell over an API, so they stall on a spinner, lose a half-filled form, and teach the team to write on paper and enter it later. At which point the software has made the job slower.

The concept

Treat the phone as the primary database and the server as a replica that eventually catches up.

1. Local first

Every job, checklist, photo and signature is written to an on-device database immediately. The interface never waits on a network call to show the result of a tap.

2. A sync engine with visible state

One clear indicator: synced, pending, or needs attention. Each record carries a client-generated id, so a retry cannot create a duplicate job, and conflicts surface as a choice rather than a silent overwrite.

3. Media that respects a data cap

Photographs are compressed and queued on device, uploaded when the connection is real, and the job can be closed before they finish.

4. Built for gloves and bad light

Large hit targets, high-contrast type, one-handed reach, and a checklist that remembers where the technician stopped.

What a first version covers

  • Today’s job list, available with the phone in airplane mode
  • Structured checklists with photo and signature capture
  • Background sync with an honest status per record
  • A dispatcher view of what has actually been completed

Status

Concept work — an internal build we use to test our own sync and conflict-handling approach. It has not been deployed for a client.

Typical architecture

A machine reporting to ingest, then to a ledger and a support viewmachinelocal log firstthen publishMQTTingestcharged vs dispensedledgerhealthremote command, logged
A pattern we build from, not this project’s own design. No client data or client system is depicted.

Next

This website

Read it

Have a version of this problem?

Tell us what your setup looks like. We will tell you which parts of this apply and which do not.