What local-first software means, where the term came from, and why the difference between local-first and cloud-with-offline-mode matters to authors.
This article doesn't recommend any product, including ours. It's here because the term gets used loosely and the distinction it describes is genuinely useful.
"Local-first software" was coined in a 2019 essay by researchers at Ink & Switch — Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan — titled Local-first software: You own your data, in spite of the cloud.
The argument was not anti-cloud. It was an observation about a trade that happened almost without anyone noticing. Software moved from files on your machine to documents on a server, and in exchange for real conveniences — collaboration, sync, no backups to manage — users gave up something that had previously been unquestioned: the software kept working whether or not the company did.
The essay set out seven properties that local-first software should have. Compressed:
Points 5 and 7 are the ones that matter most to authors, and they're the ones most often left out when the term gets used as marketing.
Three architectures get described with overlapping language:
Cloud-first. The server holds the authoritative copy. Your device shows a view of it. If the service is down, you have no document. If your account is closed, you have no document. Google Docs, Notion, most web apps.
Cloud-first with offline mode. Identical, plus a local cache so you can keep working through a dropped connection. The server still holds the real copy. This is the one most often mislabeled — an app that works on a plane is not local-first.
Local-first. Your device holds the authoritative copy. Sync, if offered, is a convenience layered on top, and the file remains complete and openable without it.
The test is not "does it work offline." It's: if this company disappeared tomorrow, would I still have my work, in a form I can open?
Most software categories don't need this argument. If a photo-editing app dies you find another one. Writing is different in four ways.
A novel takes one to three years to write. A backlist compounds for decades. Authors routinely revisit material from ten or fifteen years ago — for a new edition, a boxed set, a rights reversion, a sequel nobody expected to want.
Very little software survives fifteen years. Formats do. A folder of .txt or .docx or
.md files from 2011 opens today. A subscription document from a service that shut down in
2016 does not.
For most professions software is a means to an end and the output goes elsewhere. For an author the document is the asset. There is no exported deliverable that matters more than the manuscript. Losing access to the file is losing the work.
An unpublished manuscript may sit in draft for two years. During that window it's commercially sensitive in a way that very few personal documents are. After publication it stops mattering — you want people reading it. Few other kinds of document have that sharp a before-and-after.
The strongest argument for cloud-first architecture is real-time collaboration, and it's a genuinely excellent argument — for teams. Most authors are not a team. They're one person and, occasionally, an editor receiving a file. The main benefit you're trading away is one you were unlikely to use.
The Ink & Switch essay's fifth ideal is the one authors underweight, so it's worth making concrete. Three things make a document survive:
An open or at least readable format. Plain text and Markdown are the safest — human
readable, no software required. .docx and .rtf are documented and widely supported.
Proprietary binary formats are a bet on a company. Scrivener's project format is a
reasonable middle ground because it's a folder of files you can open individually if you
have to.
A copy you physically hold. Not access to a copy. A file, on a disk, in your possession.
Portability. Can you get everything out in one operation, in a format something else can read? "Export" that produces a PDF is not portability. Export that produces your source documents is.
That's the actual checklist. Everything else in this discussion is downstream of those three.
Local-first is not free, and articles advocating it usually skip the bill.
Backup becomes your job. This is the big one. Cloud services back up automatically — inconsistently, but automatically. Take that away and replace it with nothing, and you have made your situation worse, not better. The failure isn't hypothetical; it's the most common way authors lose books.
The minimum: three copies, two kinds of media, one off-site. Encrypt the off-site copy yourself, so that "off-site" doesn't quietly reintroduce the problem you were solving. Then test a restore, once. An untested backup is a rumor.
Multi-device costs effort. Getting a draft from laptop to tablet becomes a deliberate act rather than an ambient fact.
No version history unless you build it. Cloud editors give you a free time machine. Locally, that's either a habit or a tool you set up.
Collaboration is genuinely worse. If you and a co-author write in the same document simultaneously, cloud-first wins and it isn't close. Use the right tool for that job.
Five questions. They take a few minutes and they cut through nearly all marketing language.
Local-first isn't a moral position and it isn't a whole workflow. Most working authors end up with a split: unpublished manuscripts and unreleased assets held locally, published and public material wherever is convenient, and one deliberate encrypted backup connecting the two.
The useful shift isn't away from the cloud. It's from default to decision — knowing, for each thing you make, where the real copy lives and who else can reach it.
Verified 9 August 2026.
The test is not whether it works offline, but whether your work survives the company.
An app that works on a plane is offline-capable, not local-first.
Local-first shifts the backup burden onto you — budget for that honestly.
The whole Publishing Manual, free and online: checklists, templates and decision trees for every stage, with platform figures verified against the Publishing Database.