For years, my personal website ran on WordPress.
It was hosted on WP Engine and used many of the tools I had become accustomed to working with professionally: plugins for SEO, security, content management, and the other capabilities that typically surround a WordPress website.
WordPress worked well.
The problem was that my website no longer needed most of what WordPress provided.
By 2019, the site had evolved into a relatively simple, single-page portfolio. It showcased selected projects from my career, my skills and services, testimonials, information about me, and ways to get in touch.
There was no editorial team.
There was no publishing workflow.
There were no complex content relationships or user accounts.
There was only one person maintaining it: me.
That led me to reconsider the platform itself.
Instead of asking:
How can I make my WordPress website better?
I started asking a more important question:
Does this website still need WordPress at all?
The CMS had become more infrastructure than I needed
WordPress is an extremely capable platform, and I’ve spent a significant part of my career building and managing websites with it.
But the value of a CMS depends on the problem it is solving.
A content management system becomes particularly valuable when an organization has things like:
- Frequent publishing
- Multiple content editors
- Structured or reusable content
- Approval workflows
- Integrations
- Dynamic functionality
- Nontechnical users who need to manage content
My personal portfolio had almost none of those requirements.
The content changed occasionally, but I was comfortable making those changes directly in code.
That meant I was maintaining a database-backed CMS, hosting environment, plugins, themes, PHP updates, security considerations, backups, and other dependencies primarily to serve what was ultimately a small collection of relatively static content.
The architecture was more complex than the website required.
Matching the architecture to the requirements
I decided to rebuild the site using Middleman, a Ruby-based static site generator.
Middleman provided a development environment where I could continue working with tools I enjoyed using while generating simple HTML, CSS, and JavaScript for production.
I used Haml for templating and moved the entire website into Git.
The production architecture became much simpler:
Middleman
↓
Haml / CSS / JavaScript
↓
Static build
↓
GitHub repository
↓
GitHub Pages
↓
VisitorThere was no WordPress installation running when someone visited the site.
No database query was required to generate a page.
No server-side application had to construct the experience for each request.
Middleman generated the website ahead of time, and the resulting static files could simply be served to the browser.
For this particular project, that was exactly what I needed.
Performance became simpler by design
Website performance is often approached as an optimization exercise.
Install caching.
Optimize database queries.
Reduce plugin overhead.
Configure a CDN.
Minify assets.
Tune the server.
Those techniques are all useful when the architecture requires them.
But another approach is to eliminate unnecessary work in the first place.
With a static website, the server didn’t have to execute PHP or query a WordPress database before returning my portfolio.
The production site was primarily HTML, CSS, JavaScript, images, and other static assets.
That made the performance model much simpler.
Instead of continuously optimizing a dynamic application to efficiently produce a mostly static page, I could generate the page once and serve the finished result.
For a small portfolio site, that distinction mattered.
Reducing the security surface
Security was another important consideration.
A WordPress website introduces several components that need to remain secure:
- WordPress core
- Themes
- Plugins
- PHP
- Database access
- Administrative authentication
- Hosting configuration
- Third-party dependencies
Tools such as Wordfence can help protect that environment, but they also exist because there is an application to protect.
My portfolio didn’t need visitors interacting with an administrative system or database.
Moving to a static architecture removed much of that attack surface entirely.
That doesn’t make a static website magically immune to security issues. Dependencies, source control, domains, deployment credentials, third-party JavaScript, and other areas still require proper security practices.
But there was significantly less application infrastructure exposed to the public internet.
For this website, reducing complexity was also a security strategy.
Moving the website into version control
One of my favorite parts of the migration was making Git the center of the development workflow.
With WordPress, the complete state of a website can be distributed across several places:
Theme files
Plugins
Database content
WordPress settings
Hosting configuration
Media libraryAfter the migration, much more of my website was represented directly within the repository.
Changes became part of a familiar development workflow:
Edit
↓
Test locally
↓
Commit
↓
Push
↓
DeployThat gave me a clear history of the website and made experimentation much easier.
If I changed a layout, updated a component, modified content, or adjusted styling, the change could be reviewed through Git and traced back later.
For a developer-managed website, I preferred that model over making changes through a CMS interface.
GitHub Pages simplified hosting too
I also moved the production site from WP Engine to GitHub Pages.
WP Engine is an excellent managed WordPress hosting platform, but once WordPress was removed from the architecture, managed WordPress hosting no longer made sense for the project.
GitHub Pages gave me a much simpler hosting model for a static portfolio.
My repository was already part of my development workflow, and the generated website could be published without maintaining a traditional application server.
That also reduced the ongoing cost of operating what was ultimately a small personal website.
Again, the question wasn’t whether one hosting platform was universally better than another.
It was whether I was paying for capabilities this particular website actually needed.
I wasn’t.
What I intentionally gave up
Architecture decisions always involve tradeoffs.
Moving away from WordPress meant giving up conveniences that a CMS provides.
I no longer had an administrative interface where I could log in and edit content.
There wasn’t an ecosystem of plugins available whenever I wanted to add functionality.
Adding or changing something generally meant working within the codebase, rebuilding the site, and deploying the update.
For many website owners, those would be significant disadvantages.
For me, they weren’t.
I was the developer and the content owner.
I wanted the website managed through code.
And because the site changed relatively infrequently, requiring a deployment for content changes wasn’t a meaningful operational problem.
That is what made the decision work.
Static wasn’t automatically better. It was a better fit.
This migration reinforced something I’ve carried into much larger website projects since then:
Platform decisions should start with requirements, not platform preferences.
WordPress wasn’t the wrong technology.
It had simply become more technology than this website needed.
The better architecture for my personal portfolio was one that optimized around its actual characteristics:
- Small content footprint
- Single developer
- Infrequent updates
- No database requirements
- No editorial workflow
- Performance as a priority
- Small attack surface
- Version-controlled development
- Low infrastructure requirements
Once those requirements were clear, a static architecture became an obvious option.
The architecture
My resulting stack was intentionally small:
| Area | Technology |
|---|---|
| Static site generator | Middleman |
| Language / ecosystem | Ruby |
| Templating | Haml |
| Frontend | HTML, CSS, JavaScript |
| Source control | Git / GitHub |
| Hosting | GitHub Pages |
You can still view the Middleman version of my portfolio.
Looking back, what I value most about the project isn’t any individual technology in that stack.
It’s the reasoning that led to it.
A principle I still use today
I’ve worked with websites ranging from simple static experiences to large enterprise platforms with CMSs, personalization, analytics, localization, marketing automation, search, APIs, governance requirements, and multiple teams managing content.
Those experiences have made me less interested in arguing that one platform is inherently better than another.
The more useful question is:
What is the simplest architecture that can reliably support the requirements we actually have—and the requirements we’re reasonably likely to have next?
Sometimes the answer is WordPress.
Sometimes it’s an enterprise CMS.
Sometimes it’s a headless architecture.
And sometimes it’s just a collection of static files.
For my personal website in 2019, moving from WordPress to Middleman and GitHub Pages gave me exactly what I was looking for: better alignment between the complexity of the platform and the simplicity of the website.
And in many ways, that decision changed how I evaluate web architecture projects today.
Technology should solve the problem.
It shouldn’t become the problem.
