Skip to content
Silka

Offline-first is an architecture, not a feature

You cannot add offline support to an app that assumes connectivity. What changes when the client holds authoritative state.

Engineering8 min

Field apps get used in basements, lifts, warehouses and rural dead zones — which is to say, exactly where the job is. An app that treats connectivity as normal and offline as an error state fails at the moment it matters most.

Retrofitting is where teams get hurt. Offline-first is not a caching layer you add later; it changes who owns the truth.

The client becomes authoritative — temporarily

In an offline-first design the device holds a durable local write queue and the UI reads from local state. The server is a synchronisation partner, not the source the interface waits on.

That single change ripples through everything: identifiers must be generatable on the client, every write must be idempotent, and the server needs explicit merge rules for each entity.

  • Client-generated IDs (UUIDv7 keeps them sortable).
  • Idempotency keys on every outbound operation.
  • Per-entity merge policy — last-writer-wins, append-only, or manual resolution.
  • Visible sync state so users trust what has landed.

Make sync state visible

The most valuable thing you can show a field user is what is queued and what has synced. Hidden sync produces defensive behaviour — re-scanning, re-submitting, double entry — that corrupts data more reliably than any bug.

Decide merge rules with the business, not in code review

When two devices disagree, someone has to decide who wins. That is a business rule. Proof of delivery should never be silently overwritten; a GPS position almost always should be. Write these down before implementation.

We wrote this because we had to solve it. See what we built or tell us what you're working on.

Got a product that should exist by now?Tell us about it.

Describe what has to change in your business. We will work out what that actually takes — including when it takes less than you think.