Many cloud products end with the same email. It thanks you for the years, names a date, and links an export tool. What comes out when you press the button is the part you get to keep.

When Mozilla announced in May 2025 that Pocket would close, the export it offered was a CSV of links. Not the articles. People had saved more than a decade of reading into that service, and the file that came back was a list of links. The library was what they thought they had.

Twelve years earlier, Google gave Reader’s users about 110 days’ notice, and the ending went differently. Anyone could take their subscriptions out through Takeout as OPML, an open format any competing reader could ingest. Feedly, which had been built on Reader’s own backend, could carry people across with little more than a sign-in, and it went from roughly four million users in March to twelve million by the end of May. Same kind of ending, different outcome. The difference was what the export carried: Reader’s held the whole thing people had built, a list of subscriptions; Pocket’s left out the part they valued, the reading itself.

I have come to think that is the one lesson in note-taking software that has held for twenty years — and, unexpectedly, the one that matters most right now.

The old half

Your notes should be plain text files that you hold, on storage you control. Not because plain text is nostalgic, or minimal, or pure. Because reading it has never depended on the program that wrote it. ASCII was first standardized in 1963, and RFC 20 proposed its 1968 revision for network interchange in 1969; a file written under that revision still opens, byte for byte, in the text editor of any computer you can buy today. Few of the programs that wrote such files still run.

Steph Ango — who runs Obsidian, a company whose fortunes depend on people using a note app — stated the hierarchy in 2023, in two sentences: “In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.” The file is the asset. The app is a hired renderer, kept on exactly as long as it serves the file.

None of this requires a villain. Apps get acquired, repositioned, or quietly neglected; that is the ordinary life cycle of a cloud product. Cory Doctorow’s 2022 word for one version of that arc, enshittification, caught on because it named something many people had already watched happen. In a note app the risk has a particular edge, because the switching cost is your own writing. Years of it, in a shape only one program fully reads, is what makes leaving expensive.

That half of the argument would have been true in 2015. Here is the half that wasn’t.

The new half

Language models read and write Markdown well. It is dense, structured, and legible to people, which turns out to make it legible to machines. Point an AI tool at a proprietary format and you need conversion, extraction, an API somebody has to keep alive. Point it at a folder of Markdown and the format asks for nothing extra — you still decide what to share, and with whom.

Andrej Karpathy made the machine-facing version of this case in April 2026, in a gist he called the “LLM Wiki.” He started from the deficiency of the usual retrieval setup: “the LLM is rediscovering knowledge from scratch on every question.” Nothing accumulates between questions. His alternative is almost embarrassingly plain — let the model maintain a wiki of Markdown notes, with an index it reads first and a log of what it has ingested. His own summary of the substrate is a single line: “The wiki is just a git repo of markdown files.” The payoff, in his words: “the wiki is a persistent, compounding artifact.”

Notice what was never in question there. Not the model, not the vendor, not the database. The substrate was text in a folder, because text is cheap for a machine to read and easy for a person to check.

So the two facts point the same way, and it is not a coincidence. Both come from one property: plain text does not depend on the program that made it. No app has to render it, no company has to decode it, no schema has to migrate. Whatever reads text can read your notes — a person in 2050, a model released next quarter, a shell command older than you are. Durability and AI-readiness are not two features. They are one feature, seen from two directions.

The decision that protects you from the last decade’s failure mode — vendor churn — is the same decision that prepares you for this decade’s tools. Owning your notes is not the price of using AI on them. It is the preparation.

The scaffolding was the cost

There is a third consequence, and it is less comfortable.

For about a decade, the ambitious answer to “how should I take notes?” was a system. Numbered slips with linking rules. Tag taxonomies, carefully maintained. Folder hierarchies three levels deep. Maps of content laid over webs of backlinks. The promise was that diligent enough organization would turn a pile of notes into a second brain.

Look at what all that structure was for. Some links record a real connection between ideas, and making those is thinking. But most of the apparatus — the IDs, the tags, the dutiful links — answered one question: how will I find this again? The systems were prepaid retrieval — work done by hand, at write time, so that a later search through weak tools might succeed.

That was a fair bargain when retrieval was expensive. It is a much worse one now. Full-text search across a folder of Markdown takes moments on an ordinary laptop, and a model can work across a stack of selected notes and answer questions about them — within its context limits, and not always correctly. Tending the scaffolding by hand is often keeping a card index for a library you can already talk to.

What survives is the part that was never about retrieval: the writing. Working an idea through in your own words changes what you understand, whether or not you ever find the note again. It is the step a tool can least take on your behalf without taking the understanding with it. Everything else — the filing, the linking, the taxonomy tending — is open to renegotiation.

A disclosure, and a floor

I should say where I stand, so you can weight all of this properly.

I build a note-taking app. It is local-first, works on plain Markdown files, and runs offline — which tells you where my convictions lie, and also that I have a horse in the race. Nothing below depends on it; every step works in an ordinary text editor.

What I recommend is small enough to be embarrassing: plain files, plain names, a few habits, and search.

That is not a methodology. It is a floor — four defaults that hold up under most of what you might build on top of them:

• Write in plain text. Markdown if you want structure, a bare .txt if you don’t. The test is simple: the notes stay readable with the app deleted.

• Keep the files where you can see them. A folder on storage you control, backed up the boring way. If the only path to your notes runs through a login, you are holding a lease.

• Name files so they sort themselves. Start dated notes with YYYY-MM-DD; lowercase and no spaces are a convention worth keeping. Sorting by name then sorts by date, in any file browser or command line.

• Run the export test before you trust anything. Export, open the result in a different program, read it. What survives the trip is what you can keep using.

Those four make everything above them easier to undo. Change apps, change methods, try whichever model arrives next quarter — the floor holds, and your writing stays where you put it. Attachments and app-specific features still need checking before a move; the text is the part that travels well.

An honest caveat, before you find it yourself. If your current tool delights you and exports cleanly to an open format — you have run the export recently, and opened the result — you may need none of this except confirmation. The floor is for everyone else: the people whose notes live somewhere they have never actually tried to leave.

The bet

Apps rise and decay on a cycle of years. Models leapfrog one another on a cycle of months. My bet is that the survivor of all that churn will be the dullest layer in the stack — the file, readable by anything that reads text, and improved by each new wave of tooling instead of stranded by it.

The app is a renderer. The model is a reader. The file is the only part that has to be yours.

I wrote a book that works this argument out in full: Own Your Notes in the Age of AI. It covers how note apps end and how to leave them, the craft of a plain-text system built to be kept, and two chapters on what AI should and should not do with your notes. The opening — the Introduction, Chapter 1, and three Markdown templates — is a free download: the sample.

Sources

• Mozilla Support, “Pocket is saying goodbye - What you need to know,” May 22, 2025 — https://support.mozilla.org/en-US/kb/future-of-pocket

• Mozilla Support, “How to export your Pocket saves” — https://support.mozilla.org/en-US/kb/exporting-your-pocket-list

• Google, “A second spring of cleaning,” March 13, 2013 — https://blog.google/topics/inside-google/a-second-spring-of-cleaning/

• “Feedly hits 12 million users,” GigaOM, June 19, 2013 — https://web.archive.org/web/20131127085534/http://gigaom.com/2013/06/19/feedly-hits-12-million-users-launches-web-version-and-quits-relying-on-googles-backend/

• RFC 20, “ASCII format for Network Interchange,” October 1969 — https://www.rfc-editor.org/rfc/rfc20

• Steph Ango, “File over app,” July 1, 2023 — https://stephango.com/file-over-app

• Cory Doctorow, “Social Quitting,” Medium, November 15, 2022; reprinted in Locus, January 2023 — https://locusmag.com/feature/commentary-cory-doctorow-social-quitting/

• Andrej Karpathy, “LLM Wiki,” GitHub gist, April 4, 2026 — https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f