The train loses its connection. In one app, the document remains editable. In another, a loading indicator replaces it. Both may have stored some data on the device, but they rely on that local data differently.
Local-first software treats a local copy as central to the user’s work, allowing useful operations without requiring a server to approve each change. Synchronization can then connect devices and collaborators when a network is available.
The phrase describes an architectural direction, not a certification that every feature is offline, private or permanent. Those properties need to be checked individually.
Local storage and local ownership are not identical
A cloud application can cache a page so it loads faster. The cache may be incomplete, temporary or unusable without a valid session. That differs from having a durable local document the application can open and edit independently.
The Ink & Switch essay on local-first software argues for software that combines collaboration with user control over data. Its principles go beyond the presence of files on a disk: they include offline work, longevity and the ability to keep using one’s data.
For a particular app, inspect what is actually stored and what can read it. An ordinary file format may be accessible to many programs. A local database can also be useful, but continued access may depend on the application or an export tool. Neither storage choice alone settles how easy it will be to leave.
Offline support has a boundary
Writing a note may work offline while searching an online archive, inviting a collaborator or generating a cloud-based summary does not. An app can honestly support offline editing and still have network-dependent features.
Check the operations you use most. Can the app start without a connection? Open older documents that were not recently viewed? Add attachments? Search the full local collection? Save and reopen new work after a restart?
Downloads and first-time setup can be another boundary. A feature that runs locally may need an initial model, dictionary or asset download. The useful question is whether it remains available after that setup, under the conditions in which you expect to use it.
Synchronization has to reconcile change
If two devices edit the same material while disconnected, reconnecting creates a reconciliation problem. The system must decide how to combine or present the changes.
Some applications use data structures designed to merge concurrent edits, including conflict-free replicated data types. Others use version comparisons, conflict copies or explicit user choices. Local-first does not require every product to use the same algorithm.
Even a technically successful merge may need human judgment. Two people can make incompatible changes to the meaning of a paragraph without producing a low-level file conflict. An application can preserve both edits while leaving an editorial problem to solve.
Check how the app presents conflicts and whether earlier versions remain accessible. “Sync complete” tells you that the system has finished its synchronization work; it does not necessarily mean every merged result is what you intended.
Sync is not a backup
Synchronization tries to make copies agree. A deletion or unwanted edit can therefore spread to all connected devices. A backup should provide a way to recover an earlier state even after the current copies have changed.
Useful recovery depends on retention, version history and a tested restore path. A folder appearing on two devices is not enough evidence. If both devices synchronize the same accidental deletion, the second copy offers little help.
Keep backups that are appropriate to the value of the data and periodically restore a sample. If the app stores information in a database, use a supported backup method rather than assuming that copying a file while it is being written will always produce a consistent archive.
Local does not automatically mean encrypted
Data on a laptop can be exposed through a lost device, an unlocked account, another application or a backup. Device encryption, application permissions and account security still matter.
Likewise, a local-first app can synchronize through a server with or without end-to-end encryption. Read the product’s description of what the server can access, how keys are handled and what happens during account recovery.
Network activity may also include diagnostics, licensing or optional integrations. To understand privacy, trace the data used by the feature you care about. The same approach helps when checking browser extension permissions.
Longevity depends on usable exits
A local copy improves resilience when a service is unavailable, but long-term access also depends on formats, software availability and export quality. If an application stops being maintained, can another tool read the material?
Our notes-app export guide offers a practical check: export representative content, open it outside the original application and inspect links and attachments. A readable exit matters even when the current app works well.
Choose based on the work that must survive a lost connection or a closed account. The architecture is useful when it makes that work possible; the label is only a starting point for checking it.
