Mastering Blog Management Tools

July 20, 20253 min read

I built a custom CMS after repetitive publishing tasks kept stealing time from writing. This article walks through the architecture and trade-offs, then connects them to lessons from Web Project Mechanics.

Content Strategy Series — 8 articles

Mastering Blog Management Tools

Creating a Custom CMS for Your Blog

I did not start by trying to build a CMS. I started by trying to stop repeating the same publishing tasks every time I finished a post. Metadata updates, file reshaping, and output validation across pages kept pulling time away from writing.

This article explains how I built a web application to manage blog articles, why I made specific architecture choices, and where the work parallels what I learned while building the Web Project Mechanics (WPM) framework.

Why I Built a Better Content Workflow

The core problem was workflow mismatch. General-purpose tools handled content well enough, but not in the way I publish. I needed a focused toolchain that treated article metadata, templates, and publication assets as one pipeline instead of disconnected steps.

The goal was straightforward: reduce repetitive work, keep article data consistent, and make publishing safer without adding unnecessary operational overhead.

Building the Blog Management Application

I structured the application with the Model-View-Controller (MVC) pattern to keep content models, UI concerns, and business behavior separate. That separation made iterative changes easier once requirements started shifting.

I chose JSON for article storage because it simplified integration with static build steps and made content transformation predictable. The trade-off is stricter validation discipline, but the file-level transparency was worth it.

The center of the implementation is ArticleService, which handles reading, updating, and creating article records. It also owns content-adjacent operations like sitemap generation and template creation, so related publishing logic stays in one boundary.

That centralization reduced duplication and made failures easier to diagnose, but it also meant this service needed clearer tests and guardrails because multiple publication responsibilities converge there.

The Parallels: Web Project Mechanics Revisited

If you know WPM, the similarity is practical rather than philosophical. Both projects came from repeated friction that looked small in isolation but expensive in aggregate.

WPM focused on project mechanics. This CMS focuses on content mechanics. In both cases, the real value came from making routine tasks explicit, testable, and less dependent on manual steps.

What This Build Changed

The main benefit was not novelty. It was consistency. I could move from draft to published state with fewer hand-offs and fewer format mistakes.

I also got clearer visibility into where the process was still brittle. Each time I automated one repeated step, the next constraint became obvious, which made iteration more targeted and less speculative.

Conclusion

A custom CMS is not automatically the right answer. If your publishing process is stable and low-volume, existing tools may be enough.

In my case, the recurring friction justified the investment. Building this application aligned the tooling with how I actually write and publish, and that alignment delivered more value than adding features for their own sake.