Why I Over-Engineered My Personal Blog (And Why You Should Too)
Part 2 of the “From WordPress to AI Agents” Series
Most developers have that one side project. The one that’s never finished. The one that technically “works” but is currently undergoing a “complete rewrite” for the third time.
For me, it’s my travel blog, WanderingBong.
It started as a simple place to dump photos. Today, it’s a custom-built monorepo running Node.js, Next.js, and a team of autonomous AI agents.
Is it overkill for a personal blog? Absolutely. Is it the best way to learn modern software architecture? 100%.
Here is the story of how — and why — I over-engineered my personal site, moving from a WordPress install to a futuristic “Agentic Content Engine.”
Phase 1: The “It Just Works” Era (2015)
Like 43% of the web, I started with WordPress. Because why wouldn’t you? It’s five minutes to install.
The Problem: Stick with WordPress long enough, and you stop being a creator and start being a sysadmin.
I wanted a specific layout -> Use a plugin.
The site is slow -> Install a caching plugin.
The caching plugin breaks the gallery -> Scream into the void.
I didn’t feel like a developer. I felt like I was patching leaks on a ship I didn’t build.
Phase 2: The “Headless” Pivot (2020)
When the world locked down in 2020, I nuked the site. I decided to rewrite it using the “Jamstack” architecture.
Backend: Strapi (Headless CMS)
Frontend: Next.js
Infrastructure: A single Ubuntu EC2 instance.
This was a huge step up. I learned how to manage PM2 processes to keep Node.js alive when it inevitably crashed. I wrestled with HAProxy to terminate SSL and route traffic to different ports.
And honestly? It worked fine. It was stable. It was cheap. It served the content perfectly.
Phase 3: The “ContentPlanner” Monorepo (2025)
So, if Phase 2 was working fine, why rewrite it?
Because the goal wasn’t just to have a blog. The goal was to learn.
We are entering the age of Coding Agents and AI Engineers. I didn’t want to just read about it; I wanted to build with it. I wanted to understand what happens when you treat AI not as a chatbot, but as a developer.
So, I kept the infrastructure that worked (EC2) and nuked the codebase to build a playground for my new AI team.
The Architecture: A Monorepo for Agents
I organized the codebase as a Monorepo using npm workspaces.
The Brain (
cms-be): A custom Node.js/Express backend.The Cockpit (
cms-ui): A Next.js admin dashboard.The Face (
blog-web): A public Next.js site.
The Infrastructure: Why I Stuck with EC2
In 2025, moving to Vercel is the default. But I deliberately stayed on my Ubuntu EC2 instance.
Why? Because the infra wasn’t the problem. It was already set up, paid for, and humming along nicely with PM2 and HAProxy.
Migrating to Serverless would have just been busywork. By keeping the “Boring” infrastructure stable, I could focus all my “Innovation Tokens” on the app layer — specifically, figuring out how to build with Cursor and Anti-gravity.
I didn’t want to debug serverless cold starts; I wanted to debug AI hallucinations.
The Secret Sauce: Journals & Memory
This rewrite allowed me to fix the biggest issue with AI content: Context.
If you ask ChatGPT to write a blog post, it’s generic. It doesn’t know you. To solve this, I added a new entity to my custom backend: Journals.
Journals are raw data points — quick notes, location tags, and unedited photos I capture while traveling. They aren’t blog posts. They are memories.
The AI Workflow:
cms-mcp: I built a custom Model Context Protocol server that exposes these Journals to the AI.
The Result: When I ask the agent to “Draft a post about Ladakh,” it doesn’t scrape Wikipedia. It queries my Journals via the API, sees my note about the “altitude sickness at 10,000ft,” and writes a story that actually happened to me.
Why You Should Over-Engineer
Sure, I could have stuck with the old Strapi setup. It worked.
But I wouldn’t have learned the nuances of Agentic Workflows. I wouldn’t have learned how to structure data (Journals) so an AI can use it effectively.
In a world where AI writes the code, the value of a developer isn’t in maintaining the status quo. It’s in tearing it down to see if you can build something smarter.
My blog is over-engineered. But for the first time in years, it’s teaching me something new.