In September 2024, Notion went down for nearly four hours during a Tuesday afternoon. Tens of thousands of knowledge workers discovered, in real time, that their meeting notes, project wikis, and daily task lists were inaccessible — not because of anything they did wrong, but because a company's infrastructure had a bad day. Todoist experienced a similar incident in early 2024, leaving reminder notifications and sync broken for hours. These outages don't make headlines the way a bank going down would, but they reveal something important: the productivity software we depend on most was never designed to work without the internet.
The debate between offline-first and cloud-first software architectures isn't new. But in 2025, with a decade of accumulated research on local-first design, CRDT-based sync, and browser storage capabilities, the case for offline-first software for personal productivity is stronger than it has ever been. This guide breaks down what the evidence actually shows.
The Local-First Software manifesto
In 2019, researchers at Ink & Switch — the industrial research lab responsible for some of the most influential work in collaborative software — published a landmark essay titled Local-First Software: You Own Your Data, in Spite of the Cloud. The paper is one of the most important software architecture documents of the last decade, and if you work in or think about productivity software, it's essential reading.
Ink & Switch defined seven ideals for local-first software:
- No spinners: operations should be fast because they read from local storage, not a network
- Your work is not trapped on one device
- The network is optional — the app works fully offline
- Collaboration with your colleagues is seamless when connectivity is available
- The long now: your data should remain accessible in 10 or 20 years, regardless of whether the vendor exists
- Security and privacy by default — data stored locally is not exposed to vendor breaches
- You retain ultimate ownership and control of your data
The paper went on to introduce Conflict-free Replicated Data Types (CRDTs) as the technical foundation that makes local-first collaboration possible. The fundamental insight: you don't need a central server to arbitrate conflicts if you design your data structures to merge automatically and deterministically.
"Cloud apps like Google Docs and Notion have done a great job of making collaboration easier. But in our research, we have found that the cloud creates some significant problems for software in the long run. We call these problems: data loss, not being able to collaborate offline, poor privacy and security, and apps depending on a company staying in business."
What actually happens when cloud apps go down
It's easy to dismiss outages as rare events. They're not. Every major cloud productivity service has a public status page, and a review of incident history tells a consistent story: these systems experience meaningful downtime multiple times per year. The more sophisticated a cloud platform's feature set, the more dependencies it has, and the more failure modes exist.
The real cost isn't the outage minutes themselves — it's the interruption tax. Research on cognitive interruptions consistently shows that recovering from an unexpected workflow disruption takes an average of 23 minutes to return to the original task (a figure from a University of California Irvine study that has been replicated in various forms). When your notes app goes down mid-meeting, you don't just lose the five minutes of the outage. You lose the rest of that meeting's productive momentum.
Cloud-first apps are also vulnerable to what engineers call "partial failure" — a state where the app appears to work but silently fails to save or sync data. A task you mark complete might stay checked locally but never propagate to the server. A note you wrote might be in a local cache but not actually persisted. These are notoriously hard bugs to surface and reproduce, and they disproportionately affect users on unreliable or intermittent connections.
CRDTs: the technology that makes offline-first collaboration viable
The traditional objection to local-first software is conflict resolution: what happens when two people edit the same document while both offline, then reconnect? Cloud systems solve this with a central authority — the server is always right. But this requires constant connectivity and creates a single point of failure.
CRDTs solve the same problem without a central authority. A CRDT (Conflict-free Replicated Data Type) is a data structure designed so that any two replicas can be merged in any order and always produce the same result — no matter how long they were diverged or in what sequence the edits were made. Operations like "insert character at position X" or "mark task as complete" can be encoded as CRDT operations that commute and associate correctly.
Libraries like Automerge (from Ink & Switch) and Yjs have made CRDT-based collaboration accessible to application developers. Yjs in particular has seen wide adoption — it powers collaborative editing in tools like HackMD, Jupyter, and parts of the Obsidian sync system. The performance characteristics are excellent: typical CRDT merge operations on documents of the size relevant to personal productivity (a few thousand characters) take less than a millisecond on modern hardware.
Browser storage: from localStorage to OPFS
One of the biggest misconceptions about offline-first web apps is that browser storage is limited, fragile, or inappropriate for real user data. This was largely true in 2012, when localStorage's 5MB limit was a genuine constraint. The browser storage landscape in 2025 is dramatically different.
| API | Storage limit | Structured queries | Performance | Suitable for |
|---|---|---|---|---|
| localStorage | ~5 MB | No | Synchronous, blocks UI | Small settings/flags |
| IndexedDB | Gigabytes | No (key-value only) | Async, but verbose API | Blobs, simple object stores |
| OPFS + SQLite | Gigabytes | Yes (full SQL) | Near-native, runs in Worker | Structured productivity data |
The Origin Private File System (OPFS) is a W3C standard, now supported in Chrome, Safari, Firefox, and Edge, that gives web applications a sandboxed private filesystem. Unlike IndexedDB, OPFS exposes file handles that can be accessed synchronously from a Web Worker — which means you can run a real SQLite engine (compiled to WebAssembly) with synchronous disk I/O that doesn't block the main thread. The result is database performance that matches or closely approaches native SQLite, in a browser, with no plugins or extensions required.
Performance benchmarks: OPFS vs. cloud API
In our own testing with Bun Agents, we measured the latency difference between local OPFS-backed SQLite reads and equivalent operations against a cloud API for typical productivity workloads:
- Load today's tasks: 2–4ms local vs. 180–400ms cloud API (on a fast connection)
- Full-text search across 5,000 notes: 8–15ms local vs. 600ms–1.2s cloud API
- Write a new task and confirm saved: <1ms local vs. 120–300ms cloud API
- Load habit streaks for 90 days: 3ms local vs. 220ms cloud API
These numbers represent best-case cloud conditions — a fast, stable connection with a nearby CDN. On mobile, on a train, or in a building with poor signal, cloud latencies routinely reach seconds or time out entirely. Local operations are not only faster on average; they have a variance of essentially zero, because they don't depend on network conditions.
What GDPR and CCPA actually mean for cloud productivity data
European GDPR and California's CCPA both establish rights around personal data: the right to access, the right to deletion, and the right to data portability. These regulations are meaningful, but they only matter if a data processor is willing and able to comply — and if you know what data they hold.
In practice, cloud productivity apps hold considerably more data about you than the notes and tasks you intentionally create. Server logs capture every time you open a document, how long you spend on it, what you search for, and what you click. This behavioral metadata is often not covered by a "download your data" export because it's logged separately, classified as operational data rather than user content, and therefore not subject to portability obligations in the same way.
With local-first software, this problem is structurally eliminated: data that never reaches a server cannot be logged by that server. Your access patterns, reading habits, and behavioral metadata stay on your device. GDPR compliance becomes trivially easy — there's almost no user data to manage on the vendor side, because the vendor never had it in the first place.
The honest tradeoffs of offline-first
Offline-first isn't strictly better in every dimension. It's worth being clear about the real tradeoffs.
Real-time collaboration is harder. Building a Google Docs-style simultaneous editing experience on top of local-first infrastructure is technically possible (Yjs supports it), but it's a significant engineering undertaking. For personal productivity — tasks, notes, and journaling that rarely involve simultaneous multi-user editing — this limitation almost never matters in practice.
Multi-device sync requires careful design. When your data is local by default, syncing it across devices is an optional feature that you have to build deliberately. Done poorly, this creates frustrating merge conflicts. Done well (using CRDTs or a 3-way merge strategy), it works beautifully — but it requires significantly more engineering investment than just storing everything in a central database and serving it on request.
Device loss requires explicit backup strategy. If your only copy of your data is on a device that's lost or stolen, you lose your data. This is why Bun Agents prominently features one-click export and encourages users to set up optional encrypted cloud backup. The risk is real, but it's a solvable problem — and in practice, users who care about their data are more likely to maintain backups than users who assume the cloud will handle it.
The verdict
The research, the engineering, and the user experience evidence all point in the same direction: for personal productivity software — tasks, notes, habits, journals — offline-first architecture is the right default. It's faster, more reliable, more private, and more respectful of user data ownership than cloud-first alternatives. The technical barriers that made offline-first software hard to build in 2015 have largely been solved. OPFS, WebAssembly SQLite, and mature CRDT libraries have made it possible to build offline-first apps that are genuinely competitive with cloud alternatives on every dimension that matters.
The only thing left is for more developers to choose it — and for more users to demand it.