Orthic Labs / Notes / Architecture
Architecture · local-first software
What Is Local-First Software? A Practical Seven-Question Test
Local-first software keeps the primary working state on your device and lets local work remain useful without depending on a remote service. A network may add sync, downloads or optional services, but it is not the only place the work exists.
The term is easy to reduce to “works offline.” That is incomplete. A cached web page may open offline while the server remains the authority. A desktop app may store files locally while sending every operation to an API. Local-first is a claim about architecture and user control, not the shape of the icon.
Where the idea came from
The phrase was established by the 2019 paper Local-first software: You own your data, in spite of the cloud. Its argument was not simply that local files are convenient. It joined responsive local operation with collaboration, longevity, privacy, user control and offline work.
That full vision often includes multi-device synchronization and collaboration. Orthic uses a narrower consumer test for focused desktop tools: can the core job and its authoritative working state survive without the publisher's server?
The seven-question local-first test
1. Where is the authoritative copy?
If the only complete copy lives on the provider's server, the product is cloud-first even if it keeps a local cache. A local-first product should identify the files or database on your machine and explain what, if anything, is synchronized elsewhere.
2. Can you complete the core job offline?
Disconnect the network after setup. Can you still open existing work, create a result, save it and retrieve it later? A product may reasonably need the network to download a model or installer first. The test concerns ordinary use after prerequisites are present.
3. Can you leave with usable data?
Export is part of control. The product should write standard files or provide a documented export path. A proprietary local database with no usable export can still trap the user even though it sits on their disk.
4. What happens if the publisher disappears?
The installed version should not require a routine server check merely to keep performing a local job, unless that dependency was central and disclosed. Updates may stop. Support may stop. The tool already installed should have a clear continuity story.
5. Which actions cross the network?
“Local-first” does not mean “no network.” Downloads, updates, license activation, URL fetching, Gmail synchronization and optional model providers can be legitimate. The publisher should name each boundary by action.
6. Can the user choose the remote part?
Optional synchronization or bring-your-own-provider features are stronger when they can be disabled or changed without disabling the local core. Choice turns a network feature into an extension rather than a condition of access.
7. Does the interface expose the boundary?
Architecture should be visible in product language. A button that sends a document to a provider should say so. An offline workflow should not be marketed with a vague “private” badge while the data path remains hidden.
Local-first is not the same as offline-first
Offline-first usually describes resilience: the app continues to function during network loss and synchronizes later. Local-first includes that property but asks who controls the authoritative data and whether the software remains useful without the service.
A cloud product with a sophisticated offline cache can be excellent. It is still different from a tool whose primary files and execution live on the machine.
Local-first is not the same as desktop
Installation location does not prove processing location. A desktop client can be a shell around a remote service. It may store tokens and caches locally while sending the actual work to an API.
Conversely, a browser can run meaningful work locally through browser storage and on-device code. The useful question is not “Does it have an installer?” It is “Where do the job, data and dependencies live?” Architecture is also separate from licensing, as the comparison of open source and commercial software explains.
Local-first is not a suite-wide privacy guarantee
Different products cross different boundaries. A document viewer opening a local file has a different network profile from an email client synchronizing Gmail or an extractor fetching a web article.
Orthic therefore avoids one blanket claim for every product. The rule is:
- Run the core job locally where that is honest and practical.
- Name the network paths where a connection is required.
- Do not put an undisclosed relay between the product and a chosen provider.
- Document what remains usable when the connection or publisher is absent.
That is more precise than “nothing ever uploads,” and precision is the point.
A network-boundary worksheet
Before choosing an app, fill in this table from its documentation:
| Action | Runs locally? | Contacts whom? | Data sent | Can it be disabled? |
|---|---|---|---|---|
| Install/download | ||||
| Core workflow | ||||
| Optional AI/provider feature | ||||
| Sync or URL fetch | ||||
| License check | ||||
| Update check | ||||
| Diagnostics |
If the publisher cannot complete the table, the architecture is not legible enough.
When cloud-first is the correct choice
Real-time collaboration, server-side automation, cross-device state, centralized administration and shared organizational data can justify a cloud authority. Pretending every job should be local would be as unhelpful as putting every job on a server.
Choose cloud-first when the service is the product. Choose local-first when the machine can perform the core job and local control materially improves speed, continuity or data handling.
Frequently asked questions
Does local-first software never use the internet?
No. It may use the internet for installation, updates, synchronization, URL fetching, licensing or optional providers. The important distinction is whether the core job and authoritative local state depend on that connection.
Is local-first software automatically private?
No. A local-first architecture can reduce routine data transfer, but the application can still contain telemetry, insecure storage or optional network features. Verify the actual data path and permissions.
Is every offline app local-first?
No. An offline cache may be temporary while a server remains authoritative. Local-first software gives the local state a primary role and a continuity path beyond temporary disconnection.
Can local-first software synchronize across devices?
Yes. The original local-first model includes synchronization and collaboration. The difference is that local work remains responsive and useful while synchronization operates as a layer rather than the sole authority.
Inspect the boundary, not the adjective
Read the software productization process to see where architecture becomes a product obligation. Then compare the official RightSuite catalog or inspect HeardRight and ViewRight as two live, focused desktop tools with product-specific boundaries.
About Orthic Labs: We are an independent software publisher. Read how we work and why we treat open-source ingredients as the start of a product, not the finished product.
<!-- After day 10: add reciprocal links to desktop-app-cloud-data, desktop-vs-web, and open-source-AI-to-desktop. -->