Building a writing system that can last

A writing system should make publishing easy today without making migration difficult ten years from now. Those goals sound compatible, but many tools achieve the first by quietly giving up the second.

The durable approach begins with a boring source format, a small number of explicit rules, and a build process that can be replaced.

Start with the artifact

The primary artifact is the writing itself, not the page template and not the database row. Store it in a format that remains legible without the original application.

Markdown is not perfect, but its failure mode is unusually kind: when the rendering system disappears, the source still looks like writing. A post needs only a small header and a body.

title: Building a writing system that can last
date: 2026-09-28
type: long-form
tags: [writing, systems, web]

The schema should reject mistakes early. A malformed date or unknown content type is cheaper to discover during a build than after publishing.

Make URLs a promise

A durable URL is a commitment to readers and to other writers. Slugs should therefore be plain, memorable, and independent of categories that may change.

URL pattern	Durability	Problem
/2026/09/a-title	Medium	Dates become permanent structure
/writing/a-title	Medium	Categories change
/a-title	High	The title alone owns the address

If a slug must change, add a redirect. Broken links are not merely an SEO problem; they break the web’s memory.

Keep the build replaceable

The build system has three jobs:

1. Validate the source.
2. Turn it into accessible HTML.
3. produce indexes and feeds.

It should not become the only program capable of understanding the archive. A tiny content helper is enough to establish the important policy:

export function visible(posts: Post[]) {
  return posts
    .filter((post) => !post.data.draft)
    .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
}

Everything else is presentation.

Publish for more than browsers

Readers arrive through browsers, feed readers, email, search engines, command-line tools, and increasingly software agents. A durable site should serve all of them from the same source.

That means producing full-content RSS, a small JSON index, raw Markdown, and useful metadata. These are not separate editorial workflows. They are alternate views of the same files.¹

The final test

Imagine opening the repository on an unfamiliar computer after five years. Could you find a piece of writing? Could you read it without installing anything? Could you move the archive to another generator in an afternoon?

If the answers are yes, the system is probably durable enough. Stop improving it and write.

Footnotes

1. One source also prevents quiet differences between the email version and the permanent web version. ↩