When I started this blog, I had one non-negotiable requirement: I wanted to own everything. Not "own it" in the way every hosting company promises and then quietly doesn't deliver — I mean genuinely own it. No database I can't easily move, no plugin ecosystem holding my content hostage, no drag-and-drop builder locking my design to a single platform.
Here's the story of what we built, why we built it that way, and why it might be the most underrated approach to running a personal blog in 2026.
The Problem With Everything Else
Most blogging platforms fall into two camps. The first is hosted platforms like Substack or Medium — easy to start, but you're a tenant, not an owner. The moment they change their rules, your audience and your archive are at their mercy.
The second camp is self-hosted CMS platforms like WordPress. More control, sure, but you inherit a database, a plugin dependency tree, security patches you have to chase forever, and a hosting bill that scales with complexity rather than content. Drag-and-drop builders on platforms like Hostinger sit somewhere in between — easy to start, but the design and structure stay locked inside that specific builder. Want to move to a different host or rebuild the front end your own way? You're starting from scratch.
I wanted neither. I wanted something closer to the original spirit of the web: plain files, readable by anything, movable anywhere, dependent on nothing.
What We Actually Built
The architecture is almost embarrassingly simple, which is exactly the point. Every blog post lives as a standalone PHP file inside a 'blog/' folder. There's no database. The homepage is a single PHP script that scans that folder, reads a handful of meta tags from each file — title, description, date, category, cover image — and renders the post list automatically. Publish a new post, and it just appears. No syncing, no rebuild step, no caching layer to invalidate.
On top of that minimal foundation, we layered in real functionality, piece by piece, based on what the workflow actually needed:
A proper admin panel. Instead of hand-writing HTML for every post, there's a password-protected dashboard with a rich text editor. Bold, italic, headings, blockquotes, image embeds, video embeds from YouTube or Vimeo — all through a normal writing interface. Hit publish, and the system generates the post file automatically, with all the SEO metadata baked in.
Backup and restore as a first-class feature. Because the content (posts, images, videos) lives in folders completely separate from the theme and admin code, you can redesign the entire front end — change colors, swap layouts, rebuild from scratch — and your content survives untouched. Download a backup zip, install whatever new version of the site you want, restore the zip, and every post is back exactly as it was.
Self-hosted analytics. Rather than outsourcing visitor data to Google Analytics on day one, we built a lightweight PHP tracker that logs page views, device type, browser, approximate city and country, traffic source, and even anonymous reading journeys — which posts the same visitor read, in sequence — all without third-party cookies or GDPR headaches. No external dependency, no data leaving the server.
SEO and AI-readability baked in. Every post automatically gets Open Graph tags (so links look like proper preview cards on WhatsApp or Instagram), Twitter Card tags, JSON-LD structured data for Google, a canonical URL, and an entry in an auto-generated sitemap. We also added an `llms.txt` file — an emerging standard that helps AI systems like Claude and ChatGPT understand what the site is and how it's structured, while a `robots.txt` explicitly keeps the admin panel hidden from every crawler, human and AI alike.
A footer that updates itself. Small detail, but it mattered: the copyright year increments automatically every January, and the social media icons are wired up to a single shared config file — add a URL once, and the icon appears across every page on the site simultaneously.
How We Got Here
None of this was planned upfront as a grand architecture. It evolved the way good infrastructure usually does: one real need at a time.
It started with "I want to post a blog as easily as possible, and I want full control." That single requirement ruled out drag-and-drop builders immediately, because control and lock-in are opposites. From there, every feature got added only when a genuine friction point showed up. Wanted to add images? We built the upload system and image library. Worried about losing everything if the design changed? We built backup and restore. Wanted to know who was actually reading? We built the analytics dashboard, deliberately self-hosted instead of defaulting to Google Analytics, partly to avoid the GDPR overhead of third-party trackers and partly because owning the raw data felt more aligned with the whole philosophy of the project.
The naming of the admin folder itself is a small example of the same instinct — instead of an obvious '/admin' path, it sits behind an obscure name, blocked from search engines at three separate layers (robots.txt, HTTP headers, and a noindex meta tag), so the entire backend is invisible to the outside world while staying completely usable from the front.
Why This Is Actually Beneficial
The honest case for this approach comes down to four things.
Independence.There is no platform to be at the mercy of. No pricing change, no feature deprecation, no algorithm shift can take this away, because there's no platform in the middle at all — just files on a server you control. Moving hosts is a matter of copying a folder, not running an export wizard and hoping nothing breaks.
Understanding the audience without renting the insight. Self-hosted analytics means we can see exactly which posts perform, where readers come from, what device they're on, and how their reading habits move from one post to the next — all without handing that data to a third party or asking visitors to accept a cookie banner before they've even read a sentence.
Speed, because there's almost nothing to slow it down.No database queries, no plugin bloat, no admin-ajax calls firing in the background. A page load is just PHP reading a handful of files and outputting HTML. On ordinary shared hosting, this setup comfortably handles thousands of posts before anyone would notice a millisecond of difference. Realistically, this architecture holds up for years of near-daily posting before storage or speed become a meaningful concern at all — we're talking low thousands of posts before it's even worth thinking about.
Total design freedom. Because the system was never built around a theme marketplace or a plugin ecosystem, there's nothing standing between an idea and its implementation. Want a new feature? Build it directly. Want a different look? Rewrite the template. No fighting a framework's opinions about how things should work.
What's Next
The system already supports auto-publishing teasers to LinkedIn and Substack, AI-assisted theme changes through natural language requests, and a mobile-installable version of the admin panel so posts can be written from a phone without needing a dedicated app. Each of these gets added the same way everything else did: when the need is real, not before.
If there's a single lesson in all of this, it's that the simplest possible foundation — plain files, no database, no framework — turned out to be the most flexible one. Every constraint that usually comes with "keeping it simple" never showed up, because the simplicity was the architecture, not a compromise on top of it.