Solution
Applications for people working where connectivity cannot be assumed — designed so being offline is the normal case rather than a degraded one.
Field applications are specified in meeting rooms with reliable wifi and used in basements, culverts, loading bays and rural sites. An application that stalls at the point of use is worse than the paper form it replaced.
The difficult case is not the absence of a connection, which is easy to detect. It is a connection that resolves, opens a socket and then delivers a fraction of the packets, where naive implementations hang, retry, duplicate and eventually corrupt.
Where the data feeds regulatory reporting, the gap between inspection and record becomes a compliance exposure as well as an efficiency problem.
Offline is treated as the default operating state. Every feature is specified twice, once connected and once disconnected, and the disconnected specification governs.
Before test design starts, our engineers spend time with the people who will use the product. That produces the conditions the test suite is built around: gloved hands, direct sunlight, low battery, a dropped device and a sync interrupted mid-flight.
Every write operation is classified with you as safe offline, safe with reservation, or requiring connectivity. The third category is legitimate and under-used — some operations should be blocked, and saying so clearly beats a conflict flow nobody understands.
Capabilities
Work completes on the device; the interface never blocks on the network.
Idempotent writes with client-generated identifiers and an ordered, dependency-aware queue.
Both versions preserved with provenance and a person decides, rather than silent overwrites.
Explicit state — queued, sent, failed — instead of an ambiguous spinner.
Your standards team changes inspection forms without a release cycle.
Physical device coverage plus simulated packet loss, latency and interruption.
Outcomes
What this changes for the organisation once it is running. These are the outcomes the design targets, agreed with you as measures before build starts.
Technology
Indicative rather than fixed. The specific choices follow your existing estate, your team's skills and the constraints we find during discovery, and are recorded as architecture decisions before build.
| Area | Typical choices |
|---|---|
| Mobile | Flutter or React Native, or fully native where device integration demands |
| Local storage | SQLite or Realm with a purpose-built sync layer |
| Sync service | Conflict detection with vector clocks and provenance |
| Testing | Physical device lab plus network-condition simulation |
A note on these pages. They describe the problem spaces we build for, how we approach them and the architecture we use. They are not client case studies and make no claim about specific engagements or results. Where a client agrees to be named, a full case study will be published in the same place.
More solutions
A single live picture of an operation for teams currently working from spreadsheets, email and telephone — built around the exceptions rather than the happy path.
Self-service that genuinely reduces inbound contact, designed around the moments that decide whether someone completes the task or picks up the phone.
Moving an existing estate to cloud in rehearsed waves, with the landing zone, guardrails and cost attribution established before anything moves.
Start a conversation
An hour with our team, no charge and no obligation. You will leave with a point of view on the problem whether or not you work with us.
Monday to Saturday, 10:00 – 19:00 IST
