A lot of people think they have a writing problem when they actually have a publishing-system problem.
They tell themselves they need more discipline, better habits, a cleaner routine. Sometimes that is true. But sometimes the missed posts and stalled drafts have less to do with discipline than with a publishing setup that keeps pulling attention sideways.
I know that pattern because I have done it more than once.
The first version was ordinary. I had a free WordPress blog. It worked. I could publish. Nothing was really stopping me. Then the attention drifted sideways. The blog stopped being a place to put finished writing and became a framework to improve. There were themes to choose, pieces to arrange, settings to tune, little structural decisions to make before the site could feel right enough. Weeks could pass with a tidier setup and no new post.
That kind of work is dangerously convincing. It looks adjacent to publishing, and sometimes it even feels more responsible than publishing. You are not procrastinating, exactly. You are building the blog. Except the blog can quietly become a future-facing object, always almost ready for the work that would justify all this effort.
WordPress is not the villain here. That is part of why the example matters. Nothing catastrophic had happened. The setup had simply become more vivid than the writing. Visible motion in the system started replacing visible public work.
Later, the same mistake came back in a cleaner outfit.
Ghost felt closer to the shape I wanted. Markdown helped. The writing path felt less cluttered. On paper, this should have been the version that fixed the problem. Instead, the stack grew a new side door. I ended up with Ghost plus a custom frontend, then a Vue project, then the familiar feeling that I was once again spending real creative energy on the machinery around the publication.
That second scene matters because it keeps the point honest. The problem was not just WordPress. It was not legacy software, ugly admin screens, or one early beginner mistake. Better taste in tools does not save you if the support system keeps becoming the interesting part.
This is the part I wish more small publishers named directly. A publishing system starts competing with the work when tending it feels more concrete, more rewarding, or more endless than finishing the publication it was meant to support.
You can usually see the shift in a few ways, even if you do not list them out so neatly while you are living inside it. Configuration starts outranking publication. New layers appear before there is even a steady publishing rhythm to protect. Small editorial needs keep getting answered with architecture. The system keeps moving, but the body of published work does not move with it.
At that point, the stack is no longer just support. It has started asking to become the project.
That does not mean every serious publication should stay tiny, plain, or technically boring. Some complexity earns its keep. Search can help. Better metadata can help. Redirects that protect old links can help. A calmer editorial flow can help. If a system makes it easier to publish, easier for readers to find and use the work, or easier to keep real control over the publication without inventing a second job, that complexity may be doing honest work.
The problem is the other kind. The kind that mostly creates more surfaces to adjust, more structure to maintain, more reasons to postpone the next piece until the foundation feels right. The helpful kind fades into the background once it is working. The unhelpful kind keeps creating its own maintenance loop and keeps asking for attention apart from the post in front of you.
That distinction matters because overbuilding rarely announces itself as avoidance. It usually arrives wearing ambition. You tell yourself you are making the publication more serious, more future-proof, more worthy of the work you want to do. Sometimes that is even partly true. But if the stack keeps expanding while the archive barely grows, the system has stopped answering to the publication.
I only understood the difference properly once the setup got much smaller.
The later version was not no system. It was enough system. Markdown files. One HTML template. A small server. Basic blog features like tags, updates, and search. Not because minimalism is morally superior, but because those were the parts that directly helped the publication exist. They supported writing, publishing, and reading without constantly asking for another layer to complete the picture.
That leaner setup changed the feeling of the work. The blog stopped behaving like an infrastructure hobby with an occasional writing side effect. It became a place to put finished pieces again. The machinery was still there, but it had dropped back into its proper role. It served the work well enough that I could spend my attention on publishing instead of tending the idea of publishing.
That is the test I keep coming back to now. A publishing system does not need to be primitive. It does not need to be permanent. It does not need to prove virtue through austerity. It just has to keep the work in the middle.
Before adding another layer, it is worth asking a plain question: what recent piece did this help publish? If the answer is vague, delayed, or always about the future, something has gone wrong. Not morally. Practically. The system is no longer helping you publish. It is asking to become the thing you work on instead.
If you want the neighboring Toni Notes workflow context, start with Most publishing problems are workflow problems in disguise, The last mile is part of the writing, and A tool you can leave is easier to trust.