Starting Over, Properly: Choosing a CMS and Meaning It

This is the fifth time I have started this blog.

Four previous versions, on four different domains, each beginning with genuine enthusiasm and a handful of posts, each quietly stopping. Nobody unsubscribed, because nobody could unsubscribe. The sites just sat there, gradually getting more out of date until I let the domain lapse.

I have thought about why more than is probably healthy, and I have landed somewhere slightly uncomfortable. None of them died because I ran out of things to write. I have never run out of things to write. They died because of everything between having something to say and it being published.

So this time I did the thing I would do at work. I treated it as a problem with a cause, tested for that cause specifically, and picked the tool that failed least.

Blogs Do Not Die of Silence, They Die of Friction

Here is the pattern I recognise from my own dead blogs.

You have a thought worth six hundred words. You open the site. Something needs updating. A plugin has a security notice. The editor has changed since last time and eats your formatting. You wanted a code block with syntax highlighting, and it takes four attempts. An image needs resizing before it will upload. By the time the post is live, you have spent more time on the machinery than on the writing, and the next thought worth six hundred words arrives to find you already tired.

Do that six times, and you stop opening the site. That is the whole failure mode. It is not dramatic, and it does not announce itself.

The useful thing about that diagnosis is that it makes the problem measurable. If friction is what kills blogs, then the right question about a CMS is not which one has the most features. It is: how many steps sit between a finished thought and a published post, and how often does one of those steps surprise me?

That is a testable property. So I tested it.

What I Actually Tested For

I gave each candidate the same job. Take a real post, one I had actually written, with code blocks, images and internal links, and get it published. Then come back a week later and do it again, without re-reading any documentation.

That second run is the one that matters. Anything is tolerable once, when you are excited and paying attention. The question is what it feels like on a Tuesday evening eight months in, when you have half an hour and no patience.

The criteria I ended up with, roughly in order of weight:

Does it get out of the way of writing? Markdown in, Markdown out, no reformatting, no fighting a rich text editor that thinks it knows better.

How does it handle code? I write about testing frameworks and platform APIs. If code blocks are awkward, everything I want to publish is awkward.

Can I get my content out? Every dead blog taught me this one. If the export is lossy, or is really a database dump, I am renting rather than owning. I wanted a clean, portable export precisely because I have had to migrate before.

How much maintenance does it demand when I ignore it? Not how much it demands when I am paying attention. How much does it accumulate while I am not?

Does it support what I want to build later without a plugin, so that decision is not a rebuild?

Is it fast by default? Not fast after optimisation. Fast before I touch it.

Notice what is missing from that list. Themes, plugin ecosystems, page builders, marketplace size. Those are the things platform comparisons usually lead with, and not one of them has ever kept me writing.

The Long Detour Through WordPress

I should be honest about how much time I gave WordPress, because it is the most instructive part of this.

It was the obvious choice, and for a long stretch I made it work. When the default editor frustrated me, I looked for something better, and I tried most of what exists: Divi, Elementor, Bricks, GeneratePress, Oxygen, Breakdance. Each solved one thing and introduced another. Each added another layer between me and the text. Each one meant relearning an interface I had not opened in a month.

Eventually I did what an engineer does when nothing on the shelf fits. I built my own theme. Then, still unsatisfied, I built my own page builder.

That is the moment I should have noticed something, and did not.

I had friction between writing and publishing, and I responded by building a substantial piece of software that sat between the two. It was interesting work. I enjoyed it. It was also, measured against the actual goal, months spent producing zero posts. The blog it was for did not survive.

The lesson I took from that is not that WordPress is bad. Plenty of people write on it very happily. The lesson is that WordPress is endlessly adjustable, and for someone who can build things, endless adjustability is not a feature. It is an invitation. Every hour of friction became an engineering problem, and engineering problems are more immediately satisfying than writing, so that is where the hours went.

I wanted a platform that gave me less to build.

Why Ghost

Ghost won on the criteria above rather than on enthusiasm, and it is not perfect. It won because it lost the fewest points.

The editor stays out of the way. It is Markdown-first; it does not silently rewrite what I typed, and code blocks work the first time. That sounds like a small thing. It is the single largest determinant of whether I will still be doing this next year.

Content is portable. The export is clean and complete. Having lost content to previous migrations, I now treat this as close to a hard requirement.

Membership and subscriptions are built in, not bolted on. If I ever want them, that is a settings change rather than a platform migration, which means the decision is not load-bearing today.

There is no plugin ecosystem to rot. That sounds like a limitation, and it is the point. Nothing accumulates while I am not looking, and no marketplace invites me to solve a problem I don't have. After the page builder, I consider a smaller surface area a feature rather than a compromise.

It is fast without work. Server-rendered, sensible defaults, decent structured data out of the box.

It is Node, and it is open source. I can read it, host it, and fix it. Given what I do for a living, being locked out of my own stack was never going to sit well.

Why Self-Hosted

Ghost offers a managed service, and for most people that is obviously the right answer. It removes exactly the maintenance burden I have been complaining about.

I went self-hosted anyway, for reasons specific to me rather than as general advice.

I already run dedicated servers. The marginal cost of another Node application is effectively nothing, and I am comfortable with the operational side, so the thing that makes managed hosting valuable is the thing I was going to do regardless.

More importantly, the managed tier doesn't allow custom storage adapters, and I wanted images to go through my own pipeline. That turned out to matter more than I expected, and it is a post of its own, because the default configuration will happily serve a full-size original to a phone and never mention it.

The honest cost is that self-hosting is a real ongoing responsibility. Security updates, backups, certificate renewal, the occasional evening lost to something that worked yesterday. If I am wrong about any of this, it will show up as friction, which is exactly what killed the last four.

I am aware of the irony. I took on maintenance to avoid the maintenance that stopped me from writing before. The distinction I am relying on is that server maintenance happens on my schedule, whereas platform friction happens at the precise moment I want to publish. One is a chore. The other is a wall in front of the thing I actually want to do.

Ask me in a year.

What I Am Still Not Sure About

Friction isn't the only thing that kills a blog, and I may have fixed the problem I knew how to fix instead of the one that matters most.

Here is what actually worries me. I am not planning to spend anything on marketing. No ads, no promotion, no growth strategy. Which means readers arrive slowly if they arrive at all, and I know myself well enough to admit that writing carefully into an empty room is its own kind of discouragement. The posts I am proudest of took days. It is not difficult to imagine finishing one, publishing it, watching nothing happen, and finding the next one slightly harder to start.

Paid subscriptions are not the concern. Being read at all is.

And the uncomfortable part is that all four previous versions of this blog also had roughly nobody reading them. So if low readership was the real cause of death, then everything above- the testing, the criteria, the choice of Ghost- is a well-engineered solution to the wrong problem.

I do not think it is. The friction was real, and I remember it clearly. But I would be overstating my confidence if I claimed to have diagnosed this cleanly, and a post arguing for testing your assumptions should probably admit which of its own remain untested.

The plan for that, such as it is: write things worth finding, be findable, and treat the audience as a slow compound rather than a launch. If that turns out to be insufficient, it will be the subject of a future post, assuming there are future posts.

What Happens Next

Mostly the platforms I actually work on, which currently means iOS, iPadOS, macOS, watchOS, visionOS, Android, Windows and Linux, and mostly the parts where the release notes and the reality diverge. Occasionally films, because I watch a great many of them and have opinions that need somewhere to go.

Two follow-ups are already queued. One on self-hosting Ghost properly, including the image pipeline mistakes I made and would rather you did not. One on building the theme, which isn't finished and has already taught me that designing a font is considerably easier than shipping one.

If any of that sounds useful, the subscribe box is somewhere nearby.

And if this post is still the most recent thing here in eighteen months, you will know which of the arguments above turned out to be wrong.