This note is a summary of the [original 2019 article of the same name](https://www.inkandswitch.com/essay/local-first/) that advocates for developing software that is primarily built for running locally instead of the cloud. The entirety of this piece has been summarised by Claude (Haiku). This summarisation was an attempt for me to understand the contents of the original article as I am not a software developer. Enhanced with my own edits! ## 1. Core Thesis The central idea of the _local-first software_ essay is this: software shouldn’t force users to surrender control of their own data to remote servers just to get collaboration and cross-device access. It argues that you can (and should) design applications so that **the authoritative copy of a user’s data lives locally** — on their device — and only syncs with other devices or users in a secondary, optional way. This gives users **better ownership, privacy, performance, resilience, and longevity**, without losing out on collaboration features that have made cloud apps popular. At its heart, local-first flips the dominant “cloud-first” model on its head: instead of _server as single source of truth_, it proposes _local device as primary_, with synchronization layered on top. ## 2. Supporting Arguments The essay builds its case through a mix of user-centric ideals and technical insights — sketching both _why_ local-first matters and _how_ it could work. ### A. Problems with Cloud-First Design Today’s[^1] cloud apps (Google Docs, Figma, Trello, etc) deliver seamless collaboration and multi-device access, but they also: - **Centralize data ownership and control** with the provider rather than the user. If the service goes away or changes policy, your data and workflows are stuck. - **Depend on network connectivity**, often blocking work when offline or slow[^2]. - **Exhibit latency and interface delays** because every interaction must traverse the network. These issues aren’t just technical — they affect user agency, trust, and long-term access. ### B. Seven Ideals of Local-First Software The authors outline a vision of what truly user-centric software looks like: 1. **Instant interaction** without spinners – because data is local. 2. **Work isn’t trapped on one device** – local storage syncs across devices. 3. **Network is optional** – full offline capability first. 4. **Seamless collaboration** even without a central server. 5. **Long-term accessibility** – your data stays readable decades later. 6. **Security & privacy by default** – less centralized attack surface. 7. **Ultimate user control** over data and workflows. This suite of ideals forms a coherent _value proposition_ that challenges the perceived inevitability of cloud dependence. ### C. Technical Building Blocks For real-world implementation, the essay explores: - **CRDTs (Conflict-free Replicated Data Types)** and similar data structures that allow safe, automatic sync and merge logic across devices without central coordination. - The tradeoffs of existing architectures (files, email sharing, cloud UIs, sync systems). They argue these technologies make local + collaborative feasible, not fantasy. It is to be noted that local-first does not mean NO COLLABORATION. Data from local systems is still synced upto the server, however an unavailable server will not stop client editing locally. ## 3. What are apps for which local-first apps are a good fit? From [Martin Kleppmann's 2023 talk at the Goto conference](https://www.youtube.com/watch?v=esMjP-7jlRE). ![[local-first-fits.png]] ## 4. What is a CRDT (Conflict-Free Replicated Data Types) **Original Paper:** [Conflict-free replicated Data Type](https://arxiv.org/pdf/1805.06358) As summarised by Claude :D This paper surveys Conflict-free Replicated Data Types (CRDTs), a class of data structures designed for distributed systems where replicas update state independently and may be temporarily disconnected. The central goal of CRDTs is to guarantee convergence: if all replicas eventually receive the same updates, they deterministically reach the same state without requiring coordination or conflict resolution at read or write time. The paper formalises CRDTs around the idea of strong eventual consistency. Updates can be applied locally, and replicas synchronize asynchronously. Convergence is achieved by carefully defining how concurrent updates are interpreted. Two main CRDT designs are described. State-based CRDTs periodically exchange full state and merge it using a mathematically well-defined join operation (typically a monotonic semilattice). Operation-based CRDTs propagate operations instead of state and rely on guarantees such as causal delivery to ensure consistency. The paper discusses common CRDTs such as counters, registers, and sets, highlighting how different concurrency semantics (e.g. add-wins vs remove-wins sets, last-writer-wins registers) encode application-level intent. More complex structures like lists, maps, and graphs are also covered. CRDTs trade strict consistency for availability and low latency, making them suitable for collaborative systems and geo-replicated databases. However, the paper notes limitations around metadata growth, expressiveness for certain coordination-heavy tasks, and the need for careful semantic design. [^1]: 2019 as of the time of this writing. [^2]: Think of all 2025 Cloudflare outages. I am not complaining because the outages meant that some of us didn't have to work :)