TL;DR
The essay argues that 'local-first' resists a single neat definition and should be treated as a spectrum rather than a binary label. It outlines common confusions (offline-first, serverless, multiplayer), defends optional servers and open-source requirements, and recommends practical design choices like avoiding spinners and favoring native clients.
What happened
The author revisits debates within the local-first community and explains why the label resists a simple definition. Drawing on prior essays and Martin Kleppmann’s succinct reframing, the piece emphasizes that local-first means your ability to work shouldn’t depend on another computer, but also that the notion implies multi-device support and a range of design trade-offs. The essay disputes absolutist takes that banish servers entirely, arguing instead for optional, user-run services or always-on peer nodes when desirable. It reasserts the expectation that local-first implies user ownership of data and leans toward free and open-source software so users aren’t locked out when a vendor dies. Practical recommendations include avoiding UI “spinners” that hide available local data, preferring native app approaches over web-first designs for local-first goals, and recognizing that seamless multiplayer is often optional rather than mandatory.
Why it matters
- Designers and product teams need clarity on local-first trade-offs to build resilient, user-owned systems.
- Optional server support and open-source clients help users retain access and control over their data long-term.
- Avoiding reliance on constant connectivity improves usability and reduces vendor lock-in for critical tasks.
- Choosing native or non-web stacks can simplify delivering local-first behavior and reduce friction for users.
Key facts
- The author characterizes 'local-first' as a spectrum rather than a binary label.
- A useful framing: local-first means availability of another computer should not prevent work; it also usually implies multi-device support.
- Local-first is not the same as offline-first; single-device offline apps (e.g., an old spreadsheet) aren’t necessarily local-first in the intended sense.
- Servers are not forbidden under local-first; always-on nodes or user-run services can be acceptable and useful.
- Peer-to-peer tooling is common in the scene, but p2p is not a requirement—sync via a remote service can still fit local-first if users can run their own servers.
- An original local-first ideal: avoid 'spinners' and let users see previously available data immediately, even if remote sync is unreachable.
- Free and open-source software is implied by local-first goals because proprietary services can revoke sync or features when a vendor disappears.
- Building local-first apps as webapps introduces friction because web technologies and browser behaviors encourage 'phoning home' and complicate local operation.
What to watch next
- Adoption of headless always-on nodes or user-run services that bridge p2p and server models.
- How open-source licensing and vendor practices evolve to enable users to run their own sync services.
- Trends in choosing native or cross-platform frameworks over web-first architectures for local-first applications.
Quick glossary
- Local-first: A design approach prioritizing local availability and user control of data, often supporting multi-device sync without requiring remote servers.
- Offline-first: An approach where an application works without network access but may not include multi-device sync or conflict resolution.
- Peer-to-peer (p2p): A network model where nodes communicate directly with each other rather than through a central server.
- Headless service: A background node or server instance that runs continuously without a user-facing interface, used to keep data available or reduce latency.
- CRDT: Conflict-free replicated data type: a family of data structures designed to enable eventual consistency without complex conflict resolution.
Reader FAQ
Is local-first the same as offline-first?
No. Offline-first means an app works without network access; local-first usually also implies multi-device sync and guarantees that another computer’s availability won’t block you.
Does local-first ban servers or the cloud?
No. Servers are allowed and can be practical; the key is that services should be optional and users must be able to run their own nodes or services.
Must a local-first app be open source?
The essay argues that free and open-source software is implied by local-first ideals so users retain data control, though specifics of licensing or services aren’t prescribed.
Is seamless multiplayer required for local-first apps?
Not always. Multi-device sync is often essential, but real-time multiplayer and conflict resolution can be optional depending on the app’s domain.
LocalFirst: You Keep Using That Word Jan 01, 2026 in OPEN SOURCE • TECHNOLOGY local-first design 9 min read If you’ve been following the local-first scene over the past few…
Sources
- LocalFirst: You Keep Using That Word
- The Dangers of Blue-Collar Populism
- A field guide to sandboxes for AI – Luis Cardoso
- Mamdani Chooses a Veteran N.Y.C. Education Leader as …
Related posts
- Is I/O still the bottleneck for word counting on modern systems?
- Strange.website: Poetic, Uneasy Reflections on Websites, AI and Dark UX
- Reverse engineering an abandoned app: restoring TileCreatorPro access