Guides
What local-first actually means
The primary working copy should be on your device, core work should continue without a network, and synchronization should be secondary rather than the sole authority.
Scope: a concise editorial field note, not a universal recommendation, security audit, or guarantee.
Start with the working copy
Ask where the file or record that you are editing actually lives. In a local-first operating model, the device holds the primary working copy and the application can use it directly.
Core work should remain useful when the network is unavailable. A service that merely caches a cloud record for a while is not the same thing: the cloud copy is still the authority and offline behavior may be temporary.
Sync is a helper, not the foundation
Secondary synchronization can copy changes between devices, but it should not be the only place where the current state exists. That distinction matters when a provider changes terms, has an outage, or closes.
This does not mean that every local-first tool must avoid servers. It means the service should extend a usable local workflow rather than define whether the work exists at all.
A five-minute reality check
Disconnect the network and try the main task. Identify the primary copy, then inspect how backups can be reached without the application vendor. Finally ask what survives if the service servers close tomorrow.
The answers do not need to be perfect to be useful. They should be concrete enough that you can name the files, the backup location, and the steps needed to continue.
Practical checklist
- Disconnect the network and run the core task.
- Identify the primary working copy.
- Inspect backup access and recovery steps.
- Ask what survives if the service servers close.
Sources checked
These first-party or authoritative sources ground the note. Checked 2026-08-11.