Portability Is the Product: What "Decentralized" Note Apps Get Backwards

For solo builders and small teams shipping a tool where the user's own data is the value — notes, journals, second brains, and any app whose AI features run over user content. You have decided to build local-first, or you are about to. This is the part the launch copy skips.

---

The first screen: the promise that quietly reverses

You ship a local-first notes app. The pitch is on the landing page: your data is yours; it lives on your device; we can't read it. It is true when you ship it. Then a quarter later you add the feature everyone now expects — a "search my notes with AI," an "ask my vault" box — and to make it good you do the obvious thing: you sync the vault to your servers and index it there. The promise did not break because you lied. It broke because nobody wrote down what "yours" was supposed to mean after the AI arrived. (Ink & Switch, "Local-first software" names the promise precisely: apps built so users "own your data, in spite of the cloud.")

Here is the claim this piece makes, and it is an argument, not a sourced fact: for a personal-knowledge product, portability is the product; "decentralized" is only the mechanism. Users do not buy your architecture. They buy the ability to leave without losing anything — and that ability has to survive your roadmap, an acquisition, and your shutdown. The vendors that actually keep users are the ones whose export works, not the ones whose copy says your data is yours.

By the end of this piece you will have two things you can use this week:

  • The portability contract** — four clauses you write before the AI features, covering format, export, offline readability, and AI degradation.
  • The export drill** — a 20-minute test you run quarterly that tells you whether clause 2 and clause 3 are actually true.

Here is where we are going:

  • The promise vs. the mechanism** — why "decentralized" is the how and "you can leave" is the why.
  • The exit clock** — the three ways every app ends, and the one you control.
  • The AI twist** — the features that make a knowledge base valuable are the ones that re-centralize it.
  • Two live cases with opposite signs** — Simplenote's slow decline vs. Evernote's tightening that kept the exit right.
  • What good looks like** — local plain files vs. "store it in a database and serialize on the way out."
  • The portability contract and the export drill** — the reusable object.
  • Where you will get stuck** — the three objections, answered.
  • What to do first** — before you write the next feature.

---

1. The promise vs. the mechanism

"Decentralized" and "local-first" are sold as architecture choices. They are mechanism. What the user is actually buying is the exit — the guarantee that the work they put into your app is not held hostage by your decisions.

Ink & Switch's 2019 framing is still the cleanest definition of the mechanism, and it is useful because it separates the how from the why. Their seven ideals for local-first software include fast local reads, offline use, seamless collaboration, long-term data longevity — what they call "the Long Now" — and, the one everything else serves, ultimate user ownership and control. (Ink & Switch; peer-reviewed at Onward! 2019, doi:10.1145/3359591.3359737.)

Read the seven as two groups. Five of them are engineering properties you can measure in the app: latency, offline behaviour, collaboration. Two of them — longevity and ownership — are not properties of the app at all. They are properties of the file, and of what happens when you are no longer there to run the app. That is the part that does not survive contact with a product roadmap, because it is the part a local-first build can defer forever and still look finished.

The reframe is one line, and it is the thing to hold onto:

Decentralization is how the data stays close. Portability is what the user can do with it when you are gone.

The reason this matters for a builder is practical, not philosophical. If you treat "local-first" as the deliverable, you ship a synced store and call it done. If you treat "portability" as the deliverable, you ship a store and a tested exit — and the exit is what you can point a skeptical user at.

2. The exit clock: the three endings every app has

Every app your user depends on has three possible endings, and you control exactly one of them:

  • The roadmap diverges.** You keep running, but you stop investing in this particular tool. The feature your user relied on does not get worse; it just stops getting better, and slowly ages out of the platforms it runs on.
  • The acquisition.** You get bought. The buyer's incentives are not your users' incentives, and the product is folded, renamed, or left to drift.
  • The shutdown.** The servers go off. This one is not hypothetical — it is the documented norm for data-centric services.

All three end the same way for the user: they are one roadmap decision, one acquisition, or one sunset email away from a vault they can no longer open. The only defence that works against all three is a format they can read without you.

The canonical example is Google Reader. On 13 March 2013, Google announced it would retire the service as part of a "second spring of cleaning," giving users a closing window to export their feeds; the service shut on 1 July 2013. (Google, "A second spring of cleaning") Reader was beloved and data-centric, and it ended on the vendor's schedule, not the user's. That is the whole lesson: "but it is popular" is not a defence, and "we would never do that" is not a contract.

3. The AI twist: the feature that re-centralizes the data

Here is the tension that makes this a 2026 problem rather than a 2019 one.

The most valuable thing you can do with a personal knowledge base is run intelligence over the whole corpus — search it, summarize it, ask it questions across everything. That is exactly what makes cloud AI attractive: the model is better, and the index lives where the compute lives. So the natural way to add AI to a local-first tool is to upload the vault, index it server-side, and answer from there.

Notice what that does. It reverses the local-first promise — quietly, by default, with no announcement. The user's data is now on your servers, readable by you, and subject to the same three endings as any cloud app. The feature that made the notes more valuable is the one that pulled them back into the cloud.

This is not a reason to avoid AI. It is a design constraint you either choose or forfeit:

If AI is a layer over a portable corpus, keep it degradable. If AI requires the whole vault uploaded, you have re-centralized the product and called it a feature.

The mitigation is concrete and testable: prefer a local model or a local index where it is good enough; if you must call a remote model, send the minimum context needed for the request rather than the whole corpus; and guarantee that every AI feature has a defined offline behaviour — it degrades to search, or to nothing, but it does not make the core product unusable without your servers.

The honest caveat, because it is the strongest objection to all of this: local-first sync is genuinely hard and not free. Ink & Switch themselves frame the collision-free data structures behind it — CRDTs and their relatives — as a real engineering tradeoff, not a switch you flip. A rough local-first app with a broken merge story can serve a user worse than a polished cloud app with a trustworthy export. That is why the contract below leads with the exit and the export, not with the sync engine: the export is the part you can get right on day one, and it is the part that pays off in every ending.

4. Two live cases with opposite signs

The argument is not abstract. Two well-known note tools took opposite paths in the same period, and the only thing they agree on is the exit right.

Case one: Simplenote, which declined without closing the door. Automattic's official update says it plainly: "Simplenote is no longer in active development, and while the app remains available, only its basic functionality is being maintained at this time. No new features or enhancements are planned." (Simplenote forums — Customer Update) That is ending #1 from the exit clock — the roadmap diverge — caught live. A loved tool is not dead; it is frozen, and the user's data has to outlast the freeze.

One precision note, because this is exactly where a sloppy writer would overstate: this is a maintenance notice, not a shutdown. A widely-shared claim that "Simplenote is shutting down" could not be verified against any primary source, and the primary source here says the opposite of closure. Do not repeat the shutdown claim. The lesson is the slow decline, not a dramatic death.

Case two: Evernote, which tightened the free tier but kept the exit. From 4 December 2023, Evernote's Free plan was capped at fifty notes and one notebook. Read the next sentence carefully, because it is the tell: "any Free user who currently has more than fifty notes and one notebook will still be able to view, edit, export, share, and delete existing notes and notebooks." (Evernote, "Update: Evernote Free accounts will have fifty notes and one notebook") The same post markets the AI features — AI Note Cleanup and AI-Powered Search — as reasons to subscribe. (Evernote) (That AI-as-the-paid-feature framing is Evernote's positioning, not a measured retention result — treat it as a signal of where vendors put the value, not proof that AI is why users stay.)

Put the two next to each other and the line is visible. Evernote made the product less generous — a real tightening — and still had to promise the export right. Simplenote stopped investing entirely and still left the app available and exportable. Neither vendor crossed the one line, and the one thing they share is the exit. The export right is the line even a tightening or a declining vendor will not cross. That is the strongest evidence in the packet for treating portability as the thing to build first.

5. What good looks like: plain files vs. "serialize on the way out"

If portability is the product, what does a portable product actually look like in practice?

The cleanest reference is Obsidian. It stores notes as plain Markdown files locally on the user's device, is "free without limits" with no sign-up, and monetizes optional services — Sync at $4/month, Publish at $8/month — rather than the data itself. Its own FAQ is explicit: "your data is stored locally on your device, making it inaccessible to us … we never sell user data." (Obsidian — Pricing / FAQ) The file is the storage format. There is no export step to fail, because there is nothing to export from — a stranger with a text editor can open the vault in ten years.

The anti-pattern is just as instructive: store everything in a database and write a serializer for the way out. This looks disciplined — you have an "export feature," the box is ticked. But the export is now a separate code path that can drift from the schema it is supposed to represent, and every schema change is a chance for the serializer to silently lose a link, an attachment, or a field of metadata. The Long Now test exposes it instantly: could a stranger open this file in ten years without your app? If the answer requires your exporter to still be maintained, the answer is no.

The rule is not "you must use Markdown." The rule is the direction of encoding:

Plain-text-first by default, with any richer format stored as an addition — not a database-first design with a serializer bolted on for the exit.

Attachments are the part people lose. Links are the second. If your export drops the connection between two notes, the vault stops being a second brain and becomes a pile of files — which is why clause 2 below specifies lossless, and the drill in the next section is the only way to know.

6. The portability contract and the export drill

Here is the reusable object. It is four clauses, and you can write all four before you write the AI feature. Then it is one drill you run on a schedule.

The portability contract

Clause 1 — Open, documented, plain-text-first format.

The user's notes are stored in a format that is documented and readable without your software. Plain text (Markdown, or similar) is the default on disk; any richer structure is an addition layered on top, never the only place the content lives.

Clause 2 — Lossless export that preserves links, attachments, and metadata.

Export is not a dump of the text. It carries the connections between notes, the attachments, and the metadata (timestamps, tags, IDs) that make the vault a vault. "Lossless" is a claim about what a user loses when they leave, and it is only true if you test it.

Clause 3 — Local readability without your servers.

The "if we die tomorrow" test: with your servers off and your app uninstalled, can the user still open their data? Not "can they download a backup" — can they read it. Clause 1 and clause 2 together are what make this true.

Clause 4 — AI that degrades gracefully and never requires the whole vault uploaded.

Every AI feature has a defined offline behaviour. Where feasible it runs on a local model or local index; where it calls a remote model it sends the minimum context for the request and never the entire corpus. If you shut the servers off, the product gets dumber, not broken.

The export drill (quarterly, 20 minutes)

Run this yourself, the way a user would:

  • Export everything** through the public export path — the same button a user clicks, not an internal script. If you only have the internal script, you have already failed clause 2 for your users.
  • Open it in a competitor** — or in a plain text editor and a file browser, if no competitor can read it. Count what arrives: notes, links between them, attachments, timestamps.
  • Verify nothing was lost.* Pick the ten most connected notes in the vault and confirm every link, attachment, and piece of metadata survived. Then reverse it: import the export back into your* app and confirm you can still edit everything.
  • Log the date and the result.** A drill you do not date is a drill you will stop doing.

If step 2 requires your app to be running, clause 3 is false. If step 3 loses a link, clause 2 is false. Both are fixable, and both are cheaper to fix now than after a million notes are in the vault.

7. Where you will get stuck

"Our users trust us — why build for our own shutdown?"

Because trust is exactly the asset the contract protects, and because trust is what an acquisition spends. The user is not worried that you will betray them; they are pricing in the roadmap diverge, the acquisition, and the shutdown — the three endings precisely one of which you control. A working export is not a signal that you expect to fail. It is the reason a switched-on user is willing to invest the kind of long-term data in your app that makes it valuable.

"We are local-first, so we are already portable."

Partly — architecture is necessary and not sufficient. Local-first tells you where the data lives now. It does not tell you what the data looks like on the way out, whether the export is lossless, or whether a local-first tool with a cloud AI feature has quietly shipped the vault to your servers. Clause 4 is the one most local-first tools fail without noticing, because the AI feature was added as a feature, not as a policy change.

"AI needs the data. Isn't clause 4 just refusing to compete?"

No — it is a design constraint, not a refusal. You can run a local model or a local index where the quality is good enough; you can send per-request context instead of the whole corpus; you can make the AI an optional layer over a corpus that still reads offline. What clause 4 forbids is the specific default where the only way to get AI is to hand over everything, permanently. Choose the constraint explicitly and you keep both the feature and the promise. Skip it, and the promise reverses on its own.

One honest boundary on the whole argument: no source proves that portable products out-earn cloud-locked ones, or that users will pay specifically for portability. There is no revenue or retention comparison between portable and non-portable note apps in this packet, and Evernote marketing AI as the paid feature is a positioning claim, not a measured retention driver. The thesis — portability is the product — is our inference from the Simplenote and Evernote incidents plus the regulatory direction, not a sourced fact. Treat it as a judgment this piece is making, and let your own users' behaviour tell you how much the exit is worth.

On the regulation, one more directional anchor: the EU Data Act (Regulation (EU) 2023/2854) entered into force on 11 January 2024 and into application on 12 September 2025; among its measures it "allows consumers to easily transfer data and switch between cloud providers" and prohibits unfair contracts that could prevent data-sharing. (European Commission — Data Act) GDPR Article 20 already gives individuals the right to receive their data "in a structured, commonly used and machine-readable format" and to transmit it to another controller without hindrance. (GDPR Article 20) The direction of travel is toward the exit being a right, not a favour. Building the contract now is not just good product; it is building with the current.

8. What to do first

Do not rebuild your stack today, and do not postpone the AI feature. Do one thing: write the four clauses down and run the drill once, before you ship the next feature.

Today:

  • Write the contract as four sentences** — format, export, offline readability, AI degradation. Paste it into the repo, not a note app. It is a decision record, and it constrains future work.
  • Run the export drill once, by hand.** Export through the public path, open the result without your app, and check whether links, attachments, and metadata survived. Most tools fail the first run. Finding that out now is the whole point.
  • Decide clause 4 before the AI feature, not after.** Name the offline behaviour of each AI feature on the drawing board. If an AI feature cannot answer "what does it do when our servers are down, and what does it send us?", it is not ready to be built.

That is the whole first move: four clauses, one drill, one decision made early. It costs an afternoon, needs no vendor, and converts "we're local-first" — an architecture claim your user cannot verify — into "you can leave and lose nothing," which they can test the same day.

---

The compressed ending

Remember it as four beats:

  • Portability is the product; decentralization is the mechanism.** Users do not buy your architecture. They buy the exit — the ability to leave without losing anything — and the exit is the only defence against all three endings: the roadmap diverging, the acquisition, and the shutdown.
  • The AI feature is the reversal risk.** Cloud AI needs the corpus, so bolting AI onto a local-first tool pulls the data back to your servers by default. The line is whether AI is a degradable layer over a portable corpus or a reason the vault must live with you.
  • Two live cases, one shared line.** Simplenote stopped investing but stayed exportable; Evernote tightened the free tier and still promised the export right. The exit is the line even a declining or a tightening vendor will not cross — which is why it is the part to build first, not last.
  • The contract makes it real.** Open plain-text-first format; lossless export with links and attachments; local readability without your servers; AI that degrades gracefully and needs no full upload. Then run the export drill quarterly, because a portability promise you have not tested is just launch copy.

The vendor that keeps users is not the one whose copy says your data is yours. It is the one whose export works — the one a user can test, and leave, and still stay.

---

Sources

  • Ink & Switch — "Local-first software: You own your data, in spite of the cloud" (Kleppmann, Wiggins, van Hardenberg, McGranaghan, April 2019; peer-reviewed at Onward! 2019, doi:10.1145/3359591.3359737) — the seven ideals, "the Long Now," and the ownership promise: https://www.inkandswitch.com/essay/local-first/ (canonical; the research packet cites the redirecting https://www.inkandswitch.com/local-first/)
  • European Commission — Data Act (Regulation (EU) 2023/2854; in force 11 Jan 2024, in application 12 Sep 2025; "allows consumers to easily transfer data and switch between cloud providers"): https://digital-strategy.ec.europa.eu/en/policies/data-act
  • Evernote — "Update: Evernote Free accounts will have fifty notes and one notebook" (29 Nov 2023) — the 50-note / one-notebook cap, the preserved export right, and AI Note Cleanup / AI-Powered Search as paid features: https://evernote.com/blog/evernote-free-note-limits
  • Simplenote support forums — "Customer Update on Simplenote" — "no longer in active development," basic functionality only. Maintenance-only, not a shutdown: https://forums.simplenote.com/forums/topic/customer-update-on-simplenote/
  • Obsidian — Pricing / FAQ — local plain-Markdown storage, "free without limits," Sync $4/mo and Publish $8/mo, "your data is stored locally on your device … we never sell user data": https://obsidian.md/pricing
  • GDPR Article 20 — right to data portability ("structured, commonly used and machine-readable format"; transmit to another controller without hindrance): https://gdpr-info.eu/art-20-gdpr/
  • Google — "A second spring of cleaning" (13 Mar 2013) — the Google Reader retirement announcement (service closed 1 July 2013): https://blog.google/company-news/inside-google/company-announcements/a-second-spring-of-cleaning/
  • Source signal: IdeaGenius daily brief "Decentralized Personal Knowledge Management" (ideas/decentralized-personal-knowledge-management.html). Its own cited evidence is a placeholder (a non-resolving HN item id), so the live anchors above carry the argument — the brief is the topic, not the evidence.

Precision notes: (a) "Portability is the product" is this piece's inference from the incidents and the regulatory direction, not a sourced fact; no source here shows portable products out-earn or retain better than cloud-locked ones. (b) Simplenote is in maintenance, not shutdown. (c) Evernote's AI marketing is a positioning claim, not a measured retention driver. (d) Local-first sync is a genuine engineering tradeoff (CRDTs), acknowledged by Ink & Switch itself; the contract leads with the export because it is the part you can get right on day one.

---

X entryway list (from the approved angle)

Distribution entryways named in the angle brief. Hooks are not yet written as posts — this names each post's type, the one claim or mechanism it carries, and whether it links.

  • Hook type: sharp claim.** For a note app, "decentralized" is the mechanism — portability is the product. Users do not buy your architecture; they buy the exit. → Links to article (the claim earns the read; the article supplies the four-clause contract. The link is the deepening, not the reason the claim stands).
  • Hook type: mechanism.** The AI trap in a knowledge tool: the features that make your notes more valuable are the same ones that pull them back into the cloud, un-reversing the local-first promise by default. → Links to article (the mechanism stands alone; the article explains how to keep AI offline-degradable — clause 4).
  • Hook type: build sequence.** The portability contract, in four clauses: open documented format; lossless export (links + attachments); local readability without your servers; AI that needs no full upload. → Links to article (the contract is the actionable bit; the article is the why behind each clause and the export drill).
  • Hook type: result.** Evernote shrank its free tier to 50 notes and made AI the upgrade — yet still had to promise existing users could export. The export right is the line even a tightening vendor will not cross. → Links to article (concrete before/after proof; the article generalizes it into a design rule and pairs it with Simplenote's slow decline).
  • Hook type: question the reader already has.** If you shut down tomorrow, can your users still open their data? Run the export drill and find out before they do. → Links to article (the drill is self-contained; the article provides the full test and the contract it verifies).
  • Hook type: counterpoint or limitation.** Local-first sync is genuinely hard — CRDTs, conflicts, cost. That is why "we're decentralized" is easy to promise and rarely delivered losslessly. → Links to article (names the tradeoff and keeps the piece honest; the article is where the tradeoff is unpacked and the contract reframes it as an export problem, not a sync problem).

Hook-type map: 1 = sharp claim; 2 = mechanism; 3 = build sequence; 4 = result; 5 = question; 6 = counterpoint/limitation. All six link, and each link is a bonus — every post carries a claim that stands on its own.