Every time I tell another writer I run a publication out of plain text files in a folder, I get the same look. It's a look that says: "you're a developer, sure, but I'm not going to do that." I want to make the case that they should.

The file on your laptop is the article

A plain-text article is a file on disk. You open it in a text editor. You type. You save. That's the whole writing flow. There's no "drafts in a system" concept, no "submit for approval", no getting stuck in some internal queue. The file exists or it doesn't.

For a small publication, that simplicity is the point. You don't have to learn the quirks of a particular service, you don't have to work around bugs in someone else's editor, and you don't have to explain to a guest writer how to sign in anywhere.

Keeping your work is the default

Every hosted publishing service makes you go through an export step to get your writing out. Sometimes the export is fine. Sometimes it loses things quietly (a caption here, the original date there). In every case, it's friction.

A folder of plain-text files has no export. Your writing is already in a portable form. Moving to something else — a different setup, a different service, or even back into a hosted system — comes down to copying the folder.

That portability is a kind of insurance. Whatever you're using today, you can leave tomorrow without losing anything.

A full history, without trying

Every edit I make is recorded. If I rewrite a paragraph and regret it two weeks later, I can find the original in seconds. If I want to see when a particular sentence first turned up in an article, I can.

That's the kind of editorial record most hosted services don't keep for long. A few have "revisions", but they vanish when you delete the post. Keeping your work in plain files keeps everything, forever, searchable and restorable.

And if you ever write with someone else, reviewing each other's changes line by line comes for free.

The long tail

Plain-text formatting (what people call Markdown) has been around for twenty years. It's supported by every text editor, every writing app, every note-taking tool. It'll outlive any particular service built on top of it, and probably the next one after that, too.

If I write a thousand articles over the next decade, I want them in a form that will still open in 2050. Not in a hosted service's private format. Not in a database that needs a specific piece of old software to read. Just text, in a form I can open in any editor if that's all I have.

Where it doesn't fit

Plain text isn't good for everything. It's not great for complex layouts — multiple columns, floating pull-outs, fancy tables. It's not great for rich interactive widgets. If your publication's style depends heavily on those, a hosted system is probably a better match.

For most independent publications, though, the words are the point. Good typography, a comfortable column width, a few images, the occasional pull quote. Plain text handles all of that, without ceremony.

In practice

On Project Broadsheet, every article starts with a small block of details at the top (the title, the writer, the date, the section) and then the article itself. When you save the file, the article exists. When you publish it, the site rebuilds. Readers get a fast page loaded from a place designed to serve pages quickly.

It's a boring flow, and that's the point.