Local-first architecture is not a PWA trick or a service worker strategy. It is a data architecture where the client device holds the primary copy of user data, writes happen to a local database instantly, and the server becomes a sync peer, not a gatekeeper. The Ink & Switch paper defined this in 2019 across seven ideals: fast, multi-device, offline, collaboration, longevity, privacy, and user ownership. The author dismissed it then. After shipping three production apps with local-first patterns and ripping it out of two others, he no longer does.
The piece is honest about failure cases before selling the approach. Local-first is wrong for server-generated data like analytics feeds, wrong for systems requiring ACID guarantees like payment processing, and overkill for simple CRUD tools used by five people on a stable connection. Where it works: note-taking, collaborative design, project management, field apps on unreliable networks, anything where user data privacy is a product requirement. The Git analogy is the clearest technical framing in the piece: every client holds a full or partial replica, writes commit locally, sync is push and pull in the background, and the remote is important but not the only source of truth.
The practical implication is what makes this worth reading in full. The author walks through how local-first eliminates entire categories of frontend infrastructure: no React Query, no SWR, no optimistic update logic, no Redux for server-derived state. The local database is the state. The write to local SQLite is the confirmation. His recommendation for anyone starting out is to apply local-first to one feature inside an otherwise traditional app, offline drafts in a blog editor, or real-time notes inside a REST-based tool, before committing the full architecture.
[READ ORIGINAL →]