Revisiting My Personal Site After 10 Years

I did not run a personal site for almost a decade. Coming back to it in 2026 forced a useful architecture question:

If I rebuilt this now, should I use the same stack I would have chosen ten years ago? Short answer, no.

Long answer, ten years ago, WordPress was a very rational default for this exact problem.

The decision space in the mid-2010s

Back then, the realistic options for a solo builder were narrower:

Hand-rolled HTML/CSS uploaded over FTP Low runtime complexity, high authoring friction.
WordPress on shared hosting Fast to publish, huge plugin/theme ecosystem, cheap and available everywhere.
Drupal/Joomla class CMS platforms Flexible, but heavier to configure and operate for a simple personal site.
Site builders (Wix/Squarespace class products) Fast setup, but with template and portability constraints.
Early static generators (Jekyll, etc.) Clean output, but less ergonomic workflows for non-developers and fewer integrated deployment paths.

Given those tradeoffs, WordPress often won because it balanced speed, flexibility, and cost better than the alternatives.

Why WordPress was the correct choice then

From a solutions architecture perspective, WordPress solved the non-functional requirements that mattered at the time:

Time-to-publish: very fast for blogs and updates.
Operator model: content editing without touching deploy pipelines.
Hosting compatibility: works on almost any commodity LAMP host.
Extensibility: plugins covered common needs without custom engineering.
Supportability: huge community, abundant docs, and low hiring risk.

Architecturally, it was a monolith, but a practical one. For many personal sites, that was exactly the right level of complexity.

What changed over the last decade

The platform landscape matured in ways that changed the default:

CDNs and edge hosting became commodity.
Git-based workflows became normal for content and deploys.
Static-first frameworks became significantly better.
Headless CMS platforms made content APIs first-class.
Serverless/edge functions made “just enough backend” straightforward.

At the same time, security and performance expectations rose. Running a plugin-heavy, internet-facing CMS now carries a larger operational tax than many people account for.

The option map in 2026

Today, I look at four architecture patterns:

Static-first site generators (Astro, Eleventy, Hugo) Best when content is mostly read-only and changes on publish events.
Headless CMS + static frontend Best when non-developers need editorial workflows, approvals, and previews.
Full-stack frameworks (Next.js/Remix class) Best when personalised content or server-side interactivity is a real requirement.
Managed site builders Best when operational ownership should be close to zero and customization needs are moderate.

None is universally best. They optimise for different constraints.

How I evaluate the choice now

I use a simple architecture filter:

Content velocity: How often does content change?
Interaction model: Is it mostly read-only or truly interactive?
Editorial workflow: Who publishes, and how technical are they?
Operational tolerance: Who owns patches, uptime, and incident response?
Total cost of ownership: Not just hosting, but maintenance and cognitive load.

For my personal site, the profile is clear: low change frequency, low interaction complexity, and no need for runtime personalisation.

What I chose this time

I went static-first, the site is generated ahead of time, deployed to edge infrastructure, and intentionally avoids a permanent application server. That gives me:

predictable performance
minimal attack surface
low operational overhead
a stack I can understand end to end in one sitting

WordPress is still a valid choice in many contexts, it is just no longer the obvious default for my use case.

That is the key difference from ten years ago: we now have more viable options, so architecture decisions should be requirement-driven, not habit-driven.