Every time I mention I built my own custom blog, someone asks why I didn't just use WordPress. It's a fair question. WordPress powers roughly 40% of the web. There are thousands of themes, millions of plugins, and a tutorial for everything. For most people, it's the right call.
I'm not most people.
I've been writing PHP professionally since 2003. For a personal blog on a site I manage down to the server level, reaching for WordPress would be the easy thing to do but I'd rather learn more by building one from the bottom up.
The real reasons I skipped a packaged blog engine like Wordpress.
It comes down to three things.
Security overhead. WordPress is a constant update treadmill. Core updates, theme updates, plugin updates — and if you fall behind, you're a target. I'd rather not add a dependency that requires constant monitoring and updates just to publish a blog post.
Footprint. A default WordPress install pulls in hundreds of files, a complex database schema, and a query layer that does a lot of work before it even posts a single paragraph. I needed one database table, a handful of PHP files, and some CSS. Using WordPress for that would be like renting a semi to move a couch.
This site is a portfolio. Clients hire me to build custom software. Publishing using a WordPress theme would be like a chef serving frozen dinners at their own dinner party.
What I actually built
The whole thing is about 12 files. A blog index, a single post view, an RSS feed, a simple password-protected admin for writing and managing posts, and a shared library of database functions that everything uses.
The database is just a single table with the fields you'd expect — title, slug, body, excerpt, category, tags, publish date, status, and SEO overrides for meta title and description. Nothing fancy or groundbreaking, just what the blog actually needs.
Clean URLs — /blog/post-title instead of /blog/post.php?slug=post-title — are handled by two lines in .htaccess. Each post automatically gets proper structured data, Open Graph tags, and a canonical URL without me having to remember to fill anything in. The SEO fields in the admin let me override any of it when I want to.
The admin is intentionally minimal and easy to upgrade down the road. For now, I write HTML directly — no visual editor, no Markdown parser. I work in HTML every day anyway, so a WYSIWYG would just get in the way.
Why this matters beyond my own blog
This isn't a case against packaged blog engines like WordPress. It's a case for matching the tool to the job — which is most of what good software development actually is.
Don't get me wrong, WordPress is the right answer for a lot of problems. A business owner who needs to update their own content, a site that needs e-commerce baked in, a team that needs a structured editorial workflow — WordPress earns its place in those situations. It's just not the right answer for every situation, and knowing the difference matters.
For a personal blog on infrastructure I already own, a few hundred lines of PHP is cleaner, faster, and easier to maintain than 50,000 lines of CMS. I know exactly what every file does. There's nothing to audit, nothing to update, nothing to fight with.
The whole thing came together over a day or two of actual work, spread across a few weeks as time allowed — and drawing on patterns I've used and refined across dozens of projects over the years.
I hope you enjoyed what you read, and if you have any questions or comments, please don't hesitate to reach out.
