Why I'm building a custom blog CMS instead of using WordPress

Most of what is worth writing about happens before a project is finished: the reasoning behind a decision, the question I couldn't answer yet, the approach that turned out to be wrong. By the time an app ships, that context has faded, and writing the story means reconstructing it from the outside. I want a place to keep the thinking while the work is still happening.

Why build it myself

I am building a custom CMS to connect my writing process directly to the code and discussions I already work with. Most of that is in code, in GitHub repositories, and increasingly alongside AI tools. The editorial workflow I want is specific: an agent looks at the project work and conversations I have explicitly made available, proposes article topics from what is actually there, and I pick what is worth pursuing. A draft gets written, I edit it for voice and accuracy, and publication stays a separate decision I approve deliberately.

WordPress is a fair comparison and a capable tool. It has a mature editor, a rich plugin ecosystem, and an API that could drive an automated workflow like this one. Nothing about my choice depends on WordPress being unable to do it. The difference is fit: building my own lets me shape the editorial workflow around my existing code and cloud setup, decide exactly what context an assistant can see, and keep the records portable and editable, without taking on a WordPress server, database and plugin set to maintain. The tradeoff is real -- I now maintain the implementation myself -- and for a small personal site that is a price I'm willing to pay.

What the workflow looks like

In practice it already works like this. For this site, an agent could read the repository -- the editor service, the publishing pipeline, the site code -- and suggest articles grounded in what was actually built rather than in what I vaguely remember building. A separate proposal about using scripted runs and AI critics to playtest a management game came out of the same kind of review of a different project; it is a good example of a topic brief, whatever the article eventually concludes.

The boundaries matter. An assistant can only see repositories and conversations that have been made available to it -- it has no automatic knowledge of every project or session, and private or company material is off limits regardless. Nothing is watching my work and writing a diary on its own: topic selection happens before drafting, I approve what gets drafted, and publishing is a separate approval after that.

What I want out of it

I want to be able to return to a project and understand what I was thinking when I made it. The blog gives those notes a place to accumulate, and AI can help me turn the parts worth sharing into articles.