Offline-First: Why Gut Feeling Fails in Enterprise Operations

Offline-first enterprise applications need explicit rules for what a device may save, what the server must approve and what happens when records disagree. Choosing a mobile framework does not answer those questions. We recommend defining the answers before deciding how to store or synchronise the data.

The useful starting point is Ink & Switch's local-first research, which describes software that reads and writes local files without waiting for a server. For enterprise use, we recommend treating that as a working model rather than permission for every transaction. For field operations, take the local working model and define its limits around each business action.

Decide what can happen without a connection

Start with a specific workflow, such as recording an equipment inspection. Write down what the worker needs to read, which observations they can enter and which decisions require confirmation from another system. Avoid putting every action under a single promise that the app works offline.

For example, allow an inspector to record an observation against a downloaded asset list. Treat that as a proposed workflow, not a claim about a particular product. Decide separately whether the same device may authorise equipment for use. If authorisation depends on information that the device cannot establish locally, require a connected approval step.

This distinction follows from the difference between local work and shared state. The local-first paper makes the network optional for local operations, while Amazon's Dynamo paper describes sacrificing consistency under some failures to maintain availability. Neither gives a business permission to treat an unconfirmed inspection as an approved one. That decision belongs in the workflow specification.

Give saved records an explicit status

For that inspection workflow, we would distinguish a local save from server acceptance. Use wording such as saved on this device, waiting to send, accepted by the server and needs attention. Define what must be true before the app displays each status.

Require the local-save test to survive closing and reopening the app without a connection. Require the server-accepted test to check the corresponding server record. Do not label a queued observation complete if complete means an approved inspection to the operations team.

Also specify the recovery process for work that has not reached the server. Decide who handles a damaged device, a rejected record or an attachment that remains queued. The acceptance criteria should say what the worker sees and what the support team can recover. Do not promise that local storage alone prevents every form of data loss.

Make a repeated submission the same operation

AWS describes using a caller-provided request identifier to recognise duplicate requests. This is a useful basis for submitting queued work: identify the intended operation rather than assuming every incoming request represents a new action.

In the inspection example, assign an operation identifier before the first submission. Keep that identifier for later attempts to submit the same observation. Specify how the server recognises it, how long that recognition lasts and what response the device should expect. These are proposed API requirements, not properties that appear automatically when a team adds a queue.

Write an acceptance test in which the server stores the observation but the device receives no confirmation. Resubmit using the original identifier, then check that the system contains one intended observation. Add a separate test for a genuinely new observation. A duplicate-handling rule must not prevent the worker from recording another legitimate event.

Choose a rule for conflicting edits

The Dynamo paper describes application-specific reconciliation of divergent versions. The practical lesson is to decide what a conflict means for the record, rather than leaving it to whichever value arrives last.

Consider a proposed test where two disconnected inspectors edit the same asset record. Preserve both inputs during the test and decide which fields may be combined. For independent observations, consider separate records. For competing changes to an approval status, require a named reviewer or a fresh authoritative check.

Document the rule field by field. Include who can resolve a disagreement and what evidence they need. If the chosen rule discards an earlier value, make that an explicit business decision and test that the retained history meets the team's requirements. Do not present automatic merging as proof that the resulting business decision is correct.

Specify reconnection behaviour

Amazon's guidance on retries describes backoff between attempts and jitter to spread their timing. Apply that guidance when specifying how devices send queued work after reconnecting. Define a retry limit and a visible recovery route for records that still cannot be accepted.

Separate the upload plan for observations from the plan for large attachments. Consider sending changed records rather than a complete dataset, but measure the actual payload before choosing that design. Specify when to batch submissions and how the device reports partial progress. These are design choices to validate against the workflow, not guaranteed savings.

Review the record, not the spinner

For a first acceptance session, take the inspection through a local save, an app restart, a repeated submission and a conflicting edit. Inspect the device state and the server state at each point. Ask an operations colleague to explain what the displayed status permits them to do next.

At Dendro Logic, our recommendation is to turn those decisions into written acceptance criteria before implementation. A useful next step is a walkthrough of one workflow with its engineer and operational owner. Leave with the permitted offline actions, the confirmation rules and the unresolved cases recorded against that workflow.

Update, October 2026

The same concern with recoverable state appears in our later engineering work on agent memory. Resumption-First Memory describes keeping the original conversation as the canonical record and using an index to retrieve it. It is a separate application of preserving evidence for resumed work, not a mobile synchronisation implementation.

Sources

• Ink & Switch, "Local-first software: You own your data, in spite of the cloud", 1 April 2019.
• AWS, "Making retries safe with idempotent APIs", 15 January 2021.
• Werner Vogels, "Amazon's Dynamo", including the Dynamo paper, 2 October 2007.
• AWS, "Timeouts, retries, and backoff with jitter", 5 December 2019.
• Dendro Logic, "Resumption-First Memory: Design Rules for Agentic Systems", 26 May 2026. Cited in the October 2026 update only.