Data that outlives its app

I pay for note-taking apps and I would pay more. The polish is real work and it deserves the money. What I don’t want to buy along with it is the only copy of five years of my own handwriting, in a format that one company defined, that opens in one piece of software, on the platforms that company still supports.

The question I keep coming back to isn’t whether an app is good. It’s what I still have on the day it shuts down, gets acquired, or ships the pricing change that ends the relationship. For most of the software I use daily, the honest answer is: an export button I have never pressed, producing a file I have never opened, in a format nobody has promised to keep reading.

The database is not the problem

It would be easy to read this as an argument against databases, and it isn’t. Postgres is not a trap. The trap is a specific arrangement: the canonical copy of your writing lives in rows, the only thing that can assemble those rows back into a document is the vendor’s UI, and the schema is undocumented because it was never meant to be read by anyone but the app.

That arrangement has a tell. Ask what happens if the UI disappears and the data survives. For a good system the answer is “I read the files”. For the bad one it’s “I hire someone to reverse-engineer a schema dump”, which is a sentence that means the data is already gone; you just haven’t been billed for it yet.

What this site does

This blog has no CMS. The post you are reading is an object in a TypeScript file in the repository, next to the code it describes:

{
  slug: "data-that-outlives-its-app",
  title: "Data that outlives its app",
  description: "…",
  date: "2026-07-29",
  blocks: [{ type: "p", text: "I pay for note-taking apps…" }],
}

The talks are data/talks.ts. The reading list at the foot of the index is data/resources.ts. The profiles in the footer are data/contact.ts. In every case the file is the source of truth and the page is a projection of it, which means the sitemap, the structured data and the visible page cannot disagree about what exists: there is one array, and three consumers of it.

The durability falls out of that for free. Version history is git log. The backup is every clone. Editing is any text editor on any machine from the last forty years. If Next.js is gone in a decade the posts are still sitting in a plain file with the paragraphs intact, and the worst case is an afternoon writing something that walks the array and prints HTML.

What it costs

It costs a deploy to publish a typo fix, and it costs any possibility of a non-technical person editing the site. Those are real, and for a personal site they are close to free: I am the only author, and I am already in the repository when I write, because most of these posts started as comments a few directories away.

The trade gets harder as soon as there are several authors, or a marketing team, or a publish button that needs to work from a phone. I would not tell a content team to hand-edit a TypeScript array. But the principle survives the change of scale even when the implementation doesn’t: whatever writes to the database should not be the only thing that can read it back out, and the export path should be something you actually run, not a button you trust.

The test

Take the thing you would be most upset to lose. Ask what you would hold in your hands if the company that stores it announced it was closing on Friday. If the answer is a directory of files you can open, you own your work. If it is an account, you are renting it, and the rent can be raised.