Home / Client Stories / Enterprise Operations Platform / Offline-First Field Service
Solution Story · Field Service

Software for places where the internet doesn't reach

150+ technicians repair surgical instruments from mobile vans — in hospital parking garages, loading docks, and rural facilities. We built them a field service application that treats connectivity as a bonus, not a requirement.

The problem

A van is not an office

Our client's field technicians drive fully equipped repair vans to hospitals across the country. They park where they're told — usually an underground garage — and repair surgical instruments on site, all day.

The first assumption everyone makes is "give them a web app and a hotspot." Real-world testing destroyed that assumption quickly: hotspots dropped mid-save, VPNs timed out, laptops went to sleep between customers, and coverage disappeared entirely below ground.

The requirement wasn't "works with slow internet." It was "works with no internet, for a full working day, without losing a single repair record."

How we decided

Four architectures. Three rejected.

This is the part most vendors skip: what we didn't build, and why. Each alternative was evaluated — some in prototypes, one in painful real-world testing.

✕ Rejected

Traditional web application

Single database, no synchronization — the standard answer.

Why not: completely unusable without internet. A technician below ground would simply stop working.
✕ Rejected

Web app + local cache

Partial offline capability through cached data.

Why not: cache invalidation and conflict resolution complexity, with the server still in charge. Fragile exactly when it matters.
✕ Rejected — after real-world testing

Per-transaction sync

Each operation synced through its own API call.

Why not: connections dropped mid-sync, leaving orders uploaded but notes missing. Partial states became the biggest operational risk in the field.
✓ Accepted

Offline-first desktop + atomic snapshot sync

A local database on every laptop; synchronization moves the entire database as one compressed unit.

Why: either the whole sync succeeds or nothing changes. No partial states can exist, by design.
What we built

Synchronization as an all-or-nothing business event

Instead of keeping a connection alive, the application treats sync like a shipment: package everything, send it once, receive a complete replacement back.

Technician laptop Local database customers · orders · quotes · history Previous versions kept instant rollback & diagnostics Central platform Validate version Process business changes Generate fresh database ① Compress & upload entire database ② Download fresh snapshot · replace local copy Connection drops mid-transfer? Local data untouched. Just retry. Nothing to repair.
The whole database travels as one compressed unit — a sync either completes entirely or leaves no trace.
Morning

Sync once, load the day

The technician synchronizes on any available connection: assigned customers, equipment, repair history, and pricing land in the local database.

All day · offline

Work at desktop speed

Create work orders and quotes, record repairs, track instrument trays, print reports — every operation runs locally. No spinner, no signal bars.

Evening

Sync once, done

The day's work uploads as one atomic package; a fresh database comes back. If the network fails, retry later — nothing is ever half-saved.

Versioned local databases

Every laptop keeps previous database versions — instant rollback, safe upgrades, and remote diagnostics without a support visit.

Self-updating deployment

The application updates itself on launch. 150+ non-technical users, zero manual installs, minimal IT involvement in the field.

Built for the actual user

Large controls, minimal navigation, fast data entry. The users are repair specialists, not software specialists — the UI respects that.

Results

Reliability you stop thinking about

150+
field specialists on the app daily
50–70k
synchronizations every year
0
partial-sync states possible, by design
8+
years in production, architecture unchanged
Users don't care whether synchronization happens every minute. They care that their work is never lost.
Engineering lesson from eight years of field operations