← All postsEngineering

Why we built the iotoms field app offline-first (and what that actually means)

iotoms team · August 11, 2026 · 3 min read

Every van route has a dead zone: the basement stockroom, the industrial estate, the highway stretch where signal drops to one bar of nothing. If your field app needs the network to sell, your rep stops selling exactly there — or worse, starts writing sales on paper to "enter later."

We made the opposite bet: the network is optional; the sale is not.

Local-first, not cache-first

"Offline support" often means a read cache: you can see the catalog offline but not transact. That is not enough for van sales, where the whole job happens away from WiFi. The iotoms field app treats the device as the primary store of the day's truth:

  • The catalog, price rules, customer list and route plan are fully on the device before the day opens.
  • Every sale, payment, return and expense is written to a local queue first — committed on the device the moment the rep confirms it.
  • Sync is a background concern. When signal returns, the queue drains in order; nothing about selling waits for it.

The rep can run an entire route — open the day, sell every stop, take split payments, close the day — with the radio off. The console catches up the moment the van drives back into coverage.

The hard part is money math, not transport

Moving queued records over HTTP is the easy half. The half that keeps you honest is making sure that arithmetic done on the device offline matches arithmetic done on the server later — to the cent, every time.

That means one shared rounding contract: the same rules for line totals, tax, unit conversions (a price per kg applied to 1.845 kg, say) and split payments, applied identically in the app and in the back office. If the device says the day's cash is 4,211.50 and the server recomputes 4,211.49, your day close is now an argument. We treat any such divergence as a defect of the highest severity, because trust in day close is the product.

Conflicts are business questions, not merge questions

Two devices touching the same data offline will eventually disagree. We resolve conflicts with domain rules rather than generic last-write-wins: a sale is an append-only fact that cannot be "overwritten," stock movements are ordered by business time, and anything genuinely ambiguous is surfaced to the console as an exception for a human, not silently merged.

What this buys the business

Offline-first sounds like an engineering nicety until you price the alternative: paper sales entered at night, a dead zone that quietly becomes a skipped stop, a day close that cannot be trusted. A field app that keeps selling with zero signal — and reconciles to the cent when it returns — removes an entire category of shrinkage before any report ever sees it.

It is also why the demo works the way it does: put the app in airplane mode, sell a full route, and watch the console catch up when you switch it back on. That moment is usually when distributors stop asking about features.

See your own routes running on iotoms

Book a demo