Local-First Note-Taking: Why Your Notes Shouldn't Live on Someone Else's Server

Cloud note apps trade ownership for convenience. What local-first software means, the real risks of cloud-only notes, and how offline-first apps keep data yours.

· Privacy & Ownership · 7 min read

Here is a question worth sitting with for a moment: if the company behind your note app shut down next month, what would happen to ten years of your notes?

For most people the honest answer is "I'd scramble to export something before the servers went dark, and lose the rest." That answer is a design decision — one made by the app, not by you. Cloud-first note apps store the canonical copy of your thinking on their infrastructure and lend you access to it. Local-first software inverts that: the canonical copy lives on your device, and everything else — sync, backup, collaboration — is a service layered on top of data you already own.

What "local-first" actually means

The term comes from a 2019 essay by the research lab Ink & Switch, which laid out a simple test in seven ideals. The short version: your data is on your device, the app works fully offline, it stays fast because nothing waits on a network round-trip, and it keeps working — forever — even if every server involved disappears. Sync between devices is a feature, not a dependency.

Note what local-first is not:

  • It is not "offline mode." A cloud app with an offline cache still holds the real data on the server; the cache is a convenience that expires. In a local-first app the relationship is reversed.
  • It is not anti-sync or anti-cloud. Local-first apps sync — often better, because sync is designed as merging between equal copies rather than obedience to a server. Using a cloud drive as a dumb backup target is perfectly compatible.
  • It is not nostalgia for desktop software. Old desktop apps were local, but locked data into proprietary formats. Local-first pairs local storage with open, portable formats — plain text, Markdown, standard databases.

The real risks of cloud-only notes

None of these are hypothetical; each has happened to real products with real users' notes in them.

  • Shutdowns and "sunsets." Note services get acquired, pivoted, or quietly discontinued on a regular schedule. Users typically get an export window measured in weeks — for an archive built over years.
  • Pricing and feature walls. When your archive lives on their servers, "we've updated our pricing" is not an offer, it is a toll on data you already created. Device limits, locked exports, and paywalled search have all been used on exactly the users least able to leave.
  • Account lockouts. A flagged login, a lost 2FA device, an automated suspension — and your notes are intact, on hardware you will never touch, behind a support queue.
  • Privacy by policy instead of by architecture. A privacy policy is a promise that can be amended; server-side data can be scanned, subpoenaed, breached, or fed to a model under next year's terms. Notes are frequently the most sensitive text people write — health, money, relationships, half-formed opinions. Data that never leaves your device is protected by physics, not paperwork.
  • Latency, always. Even when nothing goes wrong, every sync spinner and slow load is a tax on the tool you think with. Local data makes speed the default rather than an optimization.

What you trade away — honestly

Local-first is a set of trade-offs, not a free lunch, and it is worth naming the costs. Responsibility moves to you: if your only copy is on one laptop and the laptop dies, there is no support ticket that brings it back — so backups (an export, a copy in your own cloud drive) stop being optional. Multi-device sync is harder to engineer without a central server, which is why some local-first apps sync peer-to-peer and use conflict-resolution machinery like vector clocks or CRDTs under the hood. And real-time collaboration with dozens of people remains something centralized services genuinely do better. For shared team documents, cloud tools earn their keep; for a personal knowledge base — an asset measured in decades — the trade cuts decisively the other way.

The checklist

Evaluating any note app for data ownership comes down to five questions:

  1. Does it work — fully — with the network cable unplugged?
  2. Where is the canonical copy of a note stored: my device, or their server?
  3. Can I export everything, at any moment, into an open format like Markdown?
  4. If the company disappears tomorrow, does the app keep working?
  5. Does sync require their server, or can my devices talk to each other (or to storage I control)?

How NNote answers them

NNote was built as a yes to all five, so it makes a concrete illustration of the architecture. Notes live in your browser's local database (IndexedDB) and the app is an installable PWA that runs entirely offline. There is no account because there is no server to hold one — the site itself is static files. When you want notes on a second device, the two devices connect directly over an encrypted WebRTC channel and merge changes with vector clocks; optional Google Drive backup writes to your own Drive's app storage, not to anything NNote operates. And everything exports to plain Markdown whenever you want out. The Privacy Policy is unusually short for the simple reason that there is almost no data flow to describe.

Whether or not NNote is your tool, the principle travels: your notes are one of the few digital assets you are likely to still want in thirty years. Put them somewhere whose survival does not depend on someone else's business model — and if you are building a long-term knowledge base, make ownership the first feature you evaluate, not the last.


Try it in practice: NNote is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.

← All articles