The Three Eras of Application Architecture
Era 1: Desktop (1980s–2000s)
Software ran on your computer. Your data was in files on your hard drive. Fast, private, no internet required. But no collaboration, no access from other devices, and data loss when the hard drive failed.
Era 2: Cloud-First (2005–2020s)
Software moved to the browser. Your data lives on a server. Accessible from anywhere, automatically backed up, real-time collaboration. But dependent on internet connectivity, subject to server latency, and your data lives on someone else’s infrastructure.
Era 3: Local-First (2020s–)
The best of both worlds. Your data is on your device (fast, private, offline-capable) AND synced to the cloud (accessible from anywhere, backed up, collaborative). The local copy is the source of truth. The server is a sync hub, not a requirement.
What “Local-First” Actually Means
The term “local-first” was defined in a 2019 research paper by Kleppmann et al. at Ink & Switch. The seven ideals they describe are:
- No spinners. Work happens locally, so interactions are instant.
- Your work is not trapped on one device. Sync happens across all your devices.
- The network is optional. The app works fully offline.
- Seamless collaboration. Multiple users can edit the same data simultaneously.
- The Long Now. Your data is yours, readable decades later — not locked in a proprietary cloud format.
- Security and privacy by default. Data lives on your device, not exposed on a server.
- User control. You own your data and can export it at any time.
These ideals describe a specific architectural commitment, not just “the app kind of works offline.”
Local-First vs. Offline-First
These terms are often confused. The distinction:
Offline-first — the app is designed to handle network absence gracefully. It may cache data locally, queue writes, and sync when reconnected. But the server is still the source of truth. The local cache is a convenience layer.
Local-first — the local database is the source of truth. The server is a sync and backup mechanism. If the server disappeared tomorrow, you would still have all your data in a fully functional local database.
In practice, offline-first apps tend to have a degraded experience when offline (some features don’t work, writes may not be possible). Local-first apps work identically online and offline.
The Technical Stack
Building a local-first application requires:
A local database — SQLite (via WebAssembly in browsers) is the most common choice. It provides a full relational query engine running on the client.
A sync engine — software that keeps the local database and the server database consistent. Options include PowerSync, ElectricSQL, and custom implementations using CRDTs.
Conflict resolution — a strategy for handling concurrent edits from multiple clients. Field-level LWW, CRDTs, or operational transformation, depending on the data type.
FlowEra uses SQLite-on-WASM for the local database and PowerSync for bidirectional sync. This combination provides instant local queries, automatic background sync, and full offline capability.
Why Local-First Produces Better UX
The UX benefits aren’t marginal — they’re transformative:
Every interaction is instant. Not “fast” — instant. Under 10ms for most operations. This changes the feel of the application from “using a web app” to “using a native app.” The difference is noticeable from the first click.
No loading states for data you’ve seen. When you open a board you visited yesterday, the data is already there. No spinner, no skeleton loading state, no “fetching…” message. It’s just there.
Network quality doesn’t affect experience. On a plane, on a train, on conference WiFi, on a 2G connection in rural areas — the experience is identical. You never think about your connection because the app doesn’t depend on it.
Graceful collaboration. When you’re working with a teammate, their changes appear in your view as they happen (when online). When you’re offline, you work independently and changes merge when you reconnect. There’s no “check in / check out” pattern, no locking, no “someone else is editing this” error.
The Trade-offs
Local-first architecture has real trade-offs:
Initial load time — the first time you open a workspace, the app must download the relevant data into your local database. For large workspaces, this can take several seconds.
Storage — the local database consumes browser storage. For most task management use cases, this is measured in megabytes — trivial. For applications with large binary data (images, videos), storage management becomes important.
Bundle size — the SQLite WASM binary adds to the application bundle. FlowEra mitigates this with lazy loading.
Complexity — developing a local-first application is more complex than developing a traditional web app. There are two databases to manage, a sync protocol to operate, and conflict resolution to handle.
We believe these trade-offs are worth it for applications people use frequently. The latency savings compound across every interaction, every day.