The press, not the pages

Why build a press at all

There is no shortage of places to put writing. Every one of them takes something in exchange — a layout you cannot change, a URL you do not control, an export that loses half the formatting, a feed that decides who sees the work.

The trade is usually worth it. Publishing is not the interesting part of writing, and most people are right to hand it to someone else. I built this because a few of the things I wanted are exactly the things a hosted platform cannot give you:

Long-form that stays long-form. Not every idea is an essay. Some are books, with chapters and a contents page. Some are decks, meant to be swiped through. A platform gives you one shape — the post — and everything else becomes a post with headings in it.

Content that outlives the tool. Every article, chapter and slide caption here is a plain file in a folder. If the editing application vanished tomorrow, the writing would be exactly as readable as it is today.

A publish button that means something. On most platforms “publish” means “appears in a feed.” Here it means the site is rebuilt, checked, and deployed — and the thing I just wrote is live at a URL I own.

What “the press” means

The system has two halves, and keeping them genuinely separate is the single most important decision in the whole design.

The front end is public. It renders articles, books, decks and everything around them. It has no idea an editor exists. It reads content files and turns them into pages.

The press is private. It runs on my own machine, behind a lock. It is where writing happens, where images are processed, where a deck is assembled, and where publishing is triggered. It writes content files and nothing else.

They meet at the content files and nowhere else. That is the whole contract.

The consequence of that split shows up everywhere later in this book. It is why the front end can be deployed to a CDN that has never heard of the editor. It is why the editor can be rewritten without touching a single published page. It is why the content survives both.

The shape of the rest

Twenty chapters, roughly in three groups.

The foundation — this chapter, then the front end and the content store. How pages get rendered, and where the words live.

The modules — Studio and its writing surface, books, decks, media, taxonomy, the reading experience, diagrams. Each is a self-contained capability with its own chapter and its own screenshots.

The operational half — discovery, protection, publishing, the safety net, the connected surface, containers, and moving the whole thing to a new address without losing the search ranking it had earned.

Some of these are small. The taxonomy module is a few hundred lines and one idea. Others — the deck viewer, the publishing pipeline — took several attempts to get right, and I have said so where it is useful.