There is a moment, on every site, where the software stops being software and becomes a liability. It's the moment a super stands in a level-three plant room with no signal, three defects in their head, and a tool that wants to phone home before it will let them save anything.
We built IssuesId to never have that moment.
Connectivity is the exception, not the rule
The construction industry has spent fifteen years pretending that sites are connected. They are not. Basements, lift cores, plant rooms, stairwells, the back half of a 240-dwelling block before the comms riser is live — these are dead zones, and they are exactly where the defects are.
A tool that needs connectivity doesn't degrade gracefully in those places. It fails at the worst possible time: mid-capture, with a photo half-uploaded and a description half-typed. The super learns the lesson once, and after that they stop trusting the tool. They go back to the notebook. The data never makes it into the system, and the handover report is missing the things that actually mattered.
If your software loses a defect because the wifi dropped, the super will never forgive it — and they shouldn't.
What "offline-first" actually means
"Offline support" usually means a cache and a hope. The app remembers the last thing you looked at, and maybe queues one or two writes before it gets confused. That is not what we mean.
Offline-first means the local device is the source of truth until it syncs. Every defect, photo, annotation, and status change is written to local storage first, synchronously, with no network in the loop. The UI never waits on a request. Sync is a background reconciliation that happens whenever a connection appears — and the user never has to think about it.
The practical test is simple:
- →Open the app in airplane mode.
- →Capture twelve defects with photos across four locations.
- →Close the app. Reboot the phone. Reopen in airplane mode.
- →Every defect is still there, exactly as captured.
- →Walk back to the site office. Watch them sync without a single tap.
If a tool can't pass that test, it isn't offline-first. It's online software with a safety blanket.
The hard part is reconciliation
Writing offline is easy. Merging two weeks of offline work from six devices without losing or duplicating anything is the entire problem.
We made three decisions early that have held up:
- 01Every record carries its own identity. IDs are generated on the device, not the server, so a defect created offline is the same defect after it syncs. No "temporary ID" reconciliation, no duplicates when two supers capture the same crack from different angles.
- 02Changes are append-only events, not overwrites. When two people edit the same defect offline, we don't pick a winner and silently discard the loser. We replay both changes in timestamp order and surface anything genuinely conflicting for a human to resolve.
- 03Photos sync independently of records. A defect can be complete and useful before its 4 MB photo finishes uploading over a single bar of 4G. The record lands first; the evidence catches up.
What this buys the person on site
All of that engineering disappears into one feeling: the app is always fast, and it never loses your work. The super in the plant room captures the defect, moves on, and forgets about sync entirely — because forgetting about sync is the point.
Offline-first isn't a feature we advertise to win a checkbox comparison. It's the only honest promise you can make to someone whose job happens in a basement.