The case for local-first design
Why the next generation of design tools won't live in your browser tab — and what that means for the people who use them.
A few years ago, a quiet shift started in the tools we use every day. The cloud, once the obvious answer to every collaboration question, began to look expensive, slow, and — for some kinds of work — fundamentally wrong.
Local-first software isn't a new idea. It's the default of the pre-2010 web. But the tools that built that web — Photoshop, Sketch, Sublime Text, Vim — all shared one quiet assumption: the file lived on your machine.
When collaboration tools arrived, they replaced that file with a database. In exchange for being able to work with three people at once, we gave up the ability to work offline, to fork a design, to own our work for ten years.
“Local-first isn't about nostalgia. It's about who owns the output — and who decides when to share it.”
What changes when the file is local
Three things become different, in ways that compound.
- Latency drops to zero. Every interaction is local; the cloud only sees a diff. Tools feel alive.
- Forks become free. A copy is just a folder. A merge is just a diff.
- Ownership becomes real. If the company disappears, your work doesn't.
A note on collaboration
Local-first doesn't mean local-only. The best tools in this space sync through CRDTs or simple append-only logs. You can collaborate in real time — you just don't have to.
Where this leaves us
The next wave of design tools — and the agents that work in them — won't be measured by how many features they cram into a browser tab. They'll be measured by how much they can stay out of your way.