Can local-first software use a cloud server?

Yes. Servers can assist synchronization and other functions without making every local operation depend on them.

Does offline editing solve concurrent-edit conflicts?

No. The synchronization and application design still need to handle them.

Must every AI feature work offline in a local-first editor?

Not necessarily. The feature's execution requirements are separate and should be clear.

AI Glossary / Data engineering and architecture / Advanced

Local-first software

Definition

Local-first software gives the user's local copy of data a primary role, allowing useful work without depending on a remote server for each operation. It combines local access and user control with synchronization and collaboration where needed. The approach is broader than caching a server-controlled application for occasional offline use. It does not require eliminating servers, and its benefits depend on the application's actual design.

What it means

A user should be able to keep working with their data when a network connection is unavailable, rather than merely view a temporary copy that cannot accept meaningful changes. Synchronization can exchange those changes with other devices later. The local-first perspective also asks whether users retain practical access to their work over time. For an AI-enabled application, local document editing and remote model inference are separate capabilities: the editor can work locally even if a particular AI feature still requires a server connection.

How it works

The application stores and operates on local data, then coordinates changes with other replicas through a synchronization design. Kleppmann and colleagues describe local-first principles combining collaboration with user ownership and discuss conflict-free replicated data types as a promising foundation. Such techniques address specific consistency problems; they do not decide every application meaning. The system still needs policies for conflicting intent, access, recovery and migration. A product's local-first claim should therefore be evaluated through what users can actually do and retain, rather than inferred from one implementation component.

Three practical examples

A note-taking application permits local edits during a disconnected journey and synchronizes them with another device when connectivity returns.
A collaborative planning tool keeps usable local project data while coordinating changes from several participants.
An AI writing application separates offline document work from an optional remote generation feature and makes the availability of each understandable to users.

Think of it this way

Imagine working in your own notebook and later exchanging updates with collaborators. You do not need to contact a central office before writing each sentence. However, if two people revise the same plan independently, sharing their notebooks still requires a way to reconcile the differences. Local-first software aims to preserve immediate access while supporting that exchange. The analogy does not mean that a file copy alone supplies collaboration, or that keeping data on one device makes it immune to loss.

Worked example

Consider an original shared task list initially containing tasks A and B on two devices. While disconnected, device one adds C and device two adds D. Under a stipulated merge rule that preserves distinct additions by unique task identifiers, synchronization produces A, B, C and D on both devices: four tasks. Simply replacing one device's entire list with the other's three-task version would lose an addition. The example concerns independent additions only. If both users change the due date of A differently, the application needs a defined rule or user experience for that conflict; preserving both new tasks does not solve every kind of concurrent edit.

Illustrative case study

A fictional research team chooses a local-first notebook for field work. Researchers can record observations without a connection, then synchronize when they return. During testing, the team also checks what happens when two people edit the same observation and when a device is lost before its latest changes reach another copy. Those tests reveal requirements beyond offline editing. The scenario illustrates how local operation and synchronization can support a workflow while leaving recovery and conflict interpretation as explicit design concerns. It does not claim that the architectural label guarantees backup, confidentiality or correct resolution of every disagreement.

Common misconceptions and mistakes

Local-first does not mean that servers are forbidden or that collaboration is impossible. Conversely, a temporary browser cache does not by itself establish lasting control of the user's work. Another mistake is assuming that a merge algorithm's convergence guarantees the combined content matches everyone's intent. Replicas can agree on a result that still needs human interpretation. Local storage also is not a complete backup strategy, and an AI feature may have separate network or hardware requirements. Each capability should be assessed at the level where the user depends on it.

Business use

The concept is useful when uninterrupted access, responsive interaction and long-term control of work matter. Identify which actions must remain available without a network and which require coordination with others. Test synchronization using realistic concurrent changes and explain how the application presents unresolved intent. For AI-enabled tools, distinguish local data handling from the location of model execution and the conditions under which content is sent elsewhere. Evaluate export, recovery and continued usability alongside the ordinary online experience. Those checks reveal whether the design supports the intended working practices rather than only demonstrating a short disconnected session.

Check your understanding

How many tasks existed after merging the toy independent additions?

Answer: Four.

Why could whole-list replacement lose work?

Answer: Each disconnected device initially lacked the other's addition.

Did that merge rule decide conflicting due dates?

Answer: No.

Why did the fictional team test device loss?

Answer: Unsynchronized local changes may not exist in another recoverable copy.

Related terms

Replication (statistics)
Synchronization
Offline-first design
replication
CRDT
conflict resolution
data portability

Learn next

Describe a fictional collaborative application with two offline-capable actions and one network-dependent feature. Trace independent edits on two devices, then introduce a conflicting edit to the same item. Explain what the merge mechanism guarantees, what users may still need to decide and how the application would recover work after device loss.

Sources

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan, Local-First Software: You Own Your Data, in Spite of the Cloud: https://www.inkandswitch.com/essay/local-first/ The task-list calculation, notebook analogy and field-research case are original educational illustrations. The authors' essay supports the architectural principles; the entry does not treat CRDTs as mandatory or claim that local storage automatically provides backup, privacy or offline AI inference.

Previous: Local costmap Next: Local interpretable model-agnostic explanations