I Did Not Need a CMS. I Needed a Reviewable Publishing System

When I decided to finally put this blog into production, the obvious question seemed to be: should I keep it file-based, add a Git-backed editing layer, or move to a CMS?

That turned out to be the wrong question.

The real question was narrower:

What is the simplest publishing system that keeps the work explicit, reviewable, and calm under maintenance?

I was not trying to run a newsroom. I was trying to publish serious writing without creating a second system I would have to operate.

That changed the decision.

The tempting version was more tooling

It is easy to make editorial workflow sound more sophisticated than it is.

Once you mention drafts, review, scheduling, approvals, or collaboration, a fuller CMS starts to look like the mature answer. The same thing happens with Git-backed editing layers. They look like a clean upgrade from raw files because they add nicer interfaces without forcing a full backend.

Those options are real. They solve real problems.

But for this site, they would have solved them too early.

At this stage, most of the work still looked like this:

• write locally
• refine in the repo
• keep editorial state explicit
• publish only what is ready

That is not yet a CMS problem. It is a workflow clarity problem.

What I actually needed

What I needed was not richer content infrastructure. I needed a system with a few strong properties:

• the repo stays the system of record
• editorial state is explicit instead of hidden in a UI
• publishable content stays easy to review in diffs
• the handoff into the public site is deliberate
• automation arrives after the workflow has earned it

Those requirements pushed me away from a CMS and toward a repo-native publishing system.

That is what this repository now reflects.

Why explicit state mattered more than editing comfort

A lot of publishing tooling optimizes for editing comfort first. That is reasonable if the hard problem is getting many people to write and edit in the same place.

That was not my hard problem.

My hard problem was preserving clarity about what each piece of content was, where it was in the process, and what had become safe to expose publicly.

That made explicit state more important than a nicer editor.

I would rather have a small number of plain, reviewable transitions than a smoother interface backed by hidden editorial state.

This is the same instinct that shows up in software architecture. If the important boundary is implicit, the system becomes harder to reason about as soon as pressure increases.

The decision I actually took

I kept the public site simple.

Published content lives under the contract the site expects. Editorial work happens outside the runtime surface. The handoff between the two is explicit.

That gives me a few things I care about:

• the site does not import editorial machinery it does not need
• published content remains easy to inspect and diff
• workflow decisions stay local and legible
• I can evolve the editorial machine without dragging that complexity into the deployable app

This is not the most feature-rich setup.

It is the setup that best fits the actual shape of the work.

The rule I would use again

If publishing still mostly looks like changing content in a repository, keep the system close to the repository.

If it starts to look like operating a real editorial platform, with non-technical authors, deep scheduling needs, or complex collaboration, then a CMS becomes easier to justify.

That distinction matters.

The wrong time to adopt a heavier publishing system is not when it is technically possible. It is when the workflow has not yet made the cost unavoidable.

Why this matters beyond publishing

The useful lesson for me was not only editorial.

A publishing system is still a software system. It benefits from the same discipline as the product itself:

• local knowledge over premature indirection
• explicit state over hidden workflow
• reviewability over convenience theater
• automation after stability, not before it

I did not need a CMS.

I needed a publishing system I could still reason about six months later.