The cloud ate your data
Try this thought experiment. List every cloud service where you store important data. Google Drive. Notion. Figma. Slack. Linear. Airtable. Now imagine any one of them sends you an email tomorrow: "We're shutting down. You have 30 days to export your data."
How confident are you that you'd get everything out? That the export format would be usable? That the structure, the relationships, the context you built over years of use would survive the migration?
This isn't hypothetical. It happens constantly. Google killed Google Domains, Inbox, Google+, and dozens of other products — often with minimal notice. Notion's export produces a folder of markdown files that loses most of the structure that made the data useful in the first place. When Figma briefly went down in 2024, design teams worldwide were locked out of their own work.
We've normalized something that, if you stop and think about it, is genuinely strange: storing our most important data — our thoughts, our work, our creative output — on computers we don't own, controlled by companies we don't govern, accessible only through internet connections we can't guarantee.
What "local-first" actually means
The term "local-first" was crystallized in a landmark 2019 paper by Martin Kleppmann and colleagues at Ink & Switch, a research lab focused on the future of computing. The paper, titled "Local-First Software: You Own Your Data, in Spite of the Cloud," laid out seven ideals for software that respects user ownership:
- No spinners. Your work loads instantly because the data is already on your device. No waiting for a server response to see your own files.
- Works offline. Airplane, coffee shop with bad wifi, rural area with no signal — your tool works exactly the same as it does with a gigabit connection.
- Data ownership. Your data lives in files on your machine, in formats you can read and manipulate. No API required to access your own work.
- Longevity. If the company behind the software disappears, your data doesn't. It's on your hard drive, in durable formats.
- Privacy by default. Your data never touches a server unless you explicitly choose to sync it. No one can read your notes, mine your data, or train AI models on your work.
- Collaboration when you want it. Local-first doesn't mean local-only. When you choose to share, the software syncs intelligently — but the default is private.
- No vendor lock-in. You can switch tools, back up your data, or write your own scripts against it. The data is yours in practice, not just in a terms-of-service clause.
The technical magic: CRDTs
The hardest problem in local-first software is collaboration. If everyone's data lives on their own machine, how do you handle the case where two people edit the same thing at the same time?
The answer is a data structure called a CRDT — Conflict-free Replicated Data Type. CRDTs are designed so that edits from multiple users can be merged automatically, without conflicts, without a central server acting as arbiter, and without losing anyone's work.
Here's the intuition. In a traditional cloud app, the server is the "source of truth." When two people edit simultaneously, the server decides whose edit wins. In a CRDT-based system, there is no single source of truth — each device has its own copy, and the mathematical properties of the data structure guarantee that when copies sync, they converge to the same result regardless of the order edits arrived.
This is not new computer science — CRDTs have been studied since the 2000s — but practical implementations have only recently become mature enough for production use. Libraries like Automerge and Yjs make it possible to build real applications on CRDT foundations. And the results are striking: real-time collaboration that works even when users go offline for extended periods, with no data loss and no conflict resolution dialogs.
For a cognitive workspace like Depli, CRDTs are especially important. Your thinking shouldn't be interrupted by sync conflicts. If you work on a project offline on your laptop, then open it on your desktop later, the merge should be seamless and invisible. CRDTs make that possible.
What cloud-first gets wrong
Cloud-first architecture isn't evil. It solved real problems — collaboration, accessibility, backup. But it introduced new problems that we've become so accustomed to that we've stopped noticing them:
Latency as tax. Every interaction with a cloud-first tool involves a round trip to a server. Click, wait, response. For simple actions this is imperceptible. But for fluid, creative work — the kind where you're moving fast, rearranging ideas, zooming in and out — even 100ms of latency compounds into a feeling of sluggishness that subtly degrades your thinking.
Privacy as afterthought. When your data lives on a company's servers, privacy is a policy question, not an architectural one. Policies change. Companies get acquired. Employees have access. Governments issue subpoenas. End-to-end encryption helps, but most productivity tools don't offer it — and even those that do still hold your encrypted data on their servers, creating a target.
Dependency as default. Cloud-first tools create a dependency relationship. You depend on the company's servers being up, their business being viable, their pricing remaining affordable, and their product decisions aligning with your needs. If any of these change, your options are limited: adapt, export (if possible), or lose access.
The training data question. In 2026, every cloud service with access to user data faces pressure — from investors, from competitive dynamics — to use that data for AI training. Terms of service evolve. Opt-out mechanisms are buried in settings. If your data is on someone else's server, you have limited control over how it's used.
How Depli implements local-first
Depli is built local-first from the ground up — it's not a cloud app with an offline mode bolted on. Your workspace data lives in a local database on your machine. When you open Depli, your projects load instantly because they're already there. When you work without internet, nothing changes. When you close your laptop and reopen it on a plane, everything is exactly as you left it.
For users who want cross-device access or collaboration, Depli offers optional sync. This sync is built on CRDTs, so merging is automatic and conflict-free. But sync is opt-in, per-workspace. Your private thinking stays private unless you explicitly choose to share it.
Your data is stored in open, documented formats. If you ever want to leave Depli, you can export everything — structure intact, relationships preserved — and take it with you. We believe that if your tool is good enough, you won't need lock-in to keep users. And if it's not good enough, you shouldn't be trapped.
The performance implications are significant. Operations that take 200-500ms in a cloud-first tool take single-digit milliseconds in Depli. Dragging a module across your canvas, zooming into a cluster of notes, searching across your entire workspace — these feel instant because they are. No spinners, no loading states, no "syncing..." banners. Just your data, on your machine, at the speed of your SSD.
Local-first is a values statement
Choosing local-first architecture is a technical decision, but it's also a philosophical one. It reflects a belief that your data belongs to you — not in a terms-of-service sense, but in a practical, architectural sense. It should be on your hardware, in formats you control, accessible without anyone's permission.
The best tools are the ones that still work when everything else fails — when the wifi is down, the company pivots, or the servers are unreachable. Local-first is how you build tools that endure.
We're not naive about the trade-offs. Local-first is harder to build. Sync is complex. Some features — like real-time multiplayer editing — require careful engineering. But we believe the trade-offs are worth it, especially for a cognitive workspace where the data is your thinking itself. Your thoughts should be as available, as private, and as permanent as the device in your bag.