Ten years. That's how long I spent building websites on WordPress. Themes, page builders, premium plugins, annual licences stacking up like unpaid parking tickets. It was comfortable. It was familiar. And somewhere along the way, it became a trap.
Recently, I started systematically migrating a portfolio of client websites — simple landing pages, brochure sites, "under construction" pages — away from WordPress entirely. No new CMS, no new page builder. Just clean, static HTML served from a VPS I control completely. All four. Thirty minutes. An hour before I sat down to write this article. Using a workflow I couldn't have imagined two years ago.
This is the story of why I left, what I gained, and what I honestly miss.
The WordPress Tax
Let me be honest about the maths first, because it's what finally pushed me over the edge.
A serious WordPress setup for a professional client site isn't cheap. You're looking at a premium theme, a premium page builder with an active licence, a security plugin, a caching plugin, a backup plugin, a forms plugin, possibly an SEO plugin, and hosting that can actually handle all that PHP processing without falling over. Multiply that across a portfolio of sites and you're paying thousands of euros annually — not for features your clients actively use, but for the privilege of maintaining a stack that mostly gets in your own way.
And that's before the updates. WordPress updates. Theme updates. Plugin updates. The dreaded moment when one update breaks another plugin, which breaks the page builder, which breaks the site, which breaks your Saturday morning.
For a simple landing page — a site with five pages, a contact form, and a hero section — this is absurd overhead. The technology is solving a problem that doesn't exist.
The AI-Assisted Development Shift
Here's what changed everything: AI-assisted development has reached a point where building a clean, fast, secure static site from scratch is faster than configuring WordPress.
I'm not talking about prompting an AI to spit out generic HTML. I'm talking about a structured workflow where I describe what I need — the layout, the interactions, the security headers, the nginx configuration, the deployment pipeline — and I'm working alongside an AI agent that executes, checks, fixes, and documents everything as it goes. Rate limiting, asset caching, MIME type validation, GitHub integration, auto-commit scripts. Things that used to take me half a day now happen in a single session.
The popular term "vibe coding" undersells what this actually is. It's closer to having a tireless junior developer who never skips the boring parts and actually reads the security documentation before writing the nginx config. The difference between the AI-assisted approach and traditional development is that the execution layer has collapsed. The gap between "I know how to do this" and "this is done" has shrunk from days to hours.
But — and this is the part most AI evangelists conveniently omit — you still need to know what you're doing. The AI is amplifying expertise, not replacing it. If you don't understand nginx, security headers, DNS, SSL, deployment pipelines, and server architecture, no amount of AI assistance will produce a production-grade result. You'll get something that looks right and breaks at the first real-world edge case.
What I Gained
Speed
A full static site migration — downloading the existing WordPress site, converting it to clean HTML, setting up the server configuration, SSL, security headers, GitHub repo, automated backups — now takes minutes. I migrated four client sites in a single half-hour session. That's less time than it used to take me to just configure a WordPress theme. The stack is simpler, so everything is faster: faster to build, faster to serve, faster to maintain.
Control
When something breaks on a static site, I know exactly what broke and why. There's no plugin conflict detective work, no theme override archaeology, no "did the WordPress auto-update touch something." The files are files. The nginx config is readable. The deployment is a git push.
On our own server, we run over 30 Docker containers behind nginx. Every static site is a lightweight container with a known configuration. When I need to debug something, I'm reading HTML and nginx directives — not tracing through a chain of PHP hooks, WordPress filters, and plugin overrides that nobody documented.
Security Posture
This is where the difference is most dramatic. A static site has a fundamentally smaller attack surface than a WordPress installation. No PHP execution, no database, no wp-admin endpoint for bots to hammer, no xmlrpc.php to exploit, no plugin vulnerabilities to patch every Tuesday.
I still implement proper security headers — Content Security Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, the full set. I still configure rate limiting. I still block exploit paths and suspicious user agents at the nginx level. But I'm defending a much simpler perimeter. I'm not playing whack-a-mole with WordPress vulnerability disclosures every other week.
For context: we built an entire WordPress malware scanner specifically because we kept encountering compromised WordPress installations in client environments. When your business includes cleaning up WordPress infections, the irony of continuing to deploy new WordPress sites is not lost on you.
There's another security dimension that rarely gets discussed: site isolation. On a traditional cPanel/WHM shared hosting setup, all WordPress sites share the same PHP runtime, the same filesystem namespace, the same /tmp directory. This is exactly how side-to-side contamination works — one compromised WordPress plugin can reach neighbouring sites through symlink attacks, shared temporary directories, or abusing the common process pool. We've seen this pattern repeatedly in malware cleanups: you clean site A, and it gets reinfected within hours from site B running on the same server.
With Docker containers, each site runs in its own isolated filesystem namespace, its own process space, its own network. A compromised container cannot read or write files belonging to another container. Combined with read-only filesystem mounts, dropped Linux capabilities, and separate Docker networks per project, you get genuine defence in depth. It's not VM-level isolation — containers share the host kernel — but for static sites with an already minimal attack surface, it's a meaningful additional layer that cPanel simply cannot provide.
Cost
I was already running all my client sites on a single VPS with cPanel/WHM — so this wasn't about saving on separate hosting accounts. But dropping cPanel, WHM, PHP, MySQL, and the entire WordPress stack freed up server resources dramatically. No annual theme renewals. No page builder subscriptions. No premium plugin fees. Each static site is now a lightweight nginx container. The marginal cost of adding another one is essentially zero.
Performance
Static files served directly from nginx are fast in a way that no amount of caching plugins can fully replicate. There's no PHP interpreter, no database query, no plugin chain to execute. The server finds the file and sends it. Full stop.
Lighthouse scores that used to require heroic optimisation efforts — aggressive caching, lazy loading, image compression, render-blocking CSS elimination — are now baseline. A well-structured static site with proper asset handling scores 95+ on every Lighthouse metric without trying. With WordPress, achieving the same scores was a part-time job.
What I Lost
Let me not pretend this is a pure win, because it isn't.
The Visual Editor
This is the real one. WordPress with a premium page builder gives non-technical clients a way to make changes themselves — move a section, update text, swap an image — without calling me. With a static site, that's gone. Any content change goes through me, or requires setting up a separate editing layer.
For our own site, we solved this by building custom admin tools — a content editor that parses static HTML pages and lets us modify elements through a web interface. But that's a purpose-built solution for our specific needs, not a general-purpose replacement for the WordPress editor.
For clients who want editorial independence, I still think carefully about the right solution. Sometimes that's a headless CMS. Sometimes it's accepting that the client was never actually editing their site anyway — they were paying for the illusion of control while emailing me every change request regardless.
The Ecosystem
WordPress has a plugin for everything. Payment gateways, booking systems, membership areas, complex forms with conditional logic. Some of these I've replaced with purpose-built custom solutions. Some I've replaced with third-party embeds or API integrations. Some I haven't replaced at all because the client didn't actually need them — they just had them because they came bundled with the theme.
The honest assessment: most small business sites use about 5% of what WordPress offers. The other 95% is attack surface.
The Familiarity Factor
Clients recognise WordPress. They've heard of it. When I tell a new client their site runs on "a static stack served from nginx," I sometimes see a flicker of uncertainty. Education is part of the job now in a way it wasn't before. The conversation usually resolves quickly — "your site loads in under a second, costs less to host, and can't be hacked through a plugin vulnerability" is a compelling pitch — but it's an extra step.
Who This Is For
I want to be clear about scope. I'm not evangelising static sites as a universal replacement for WordPress. If a client runs a blog with weekly posts, a WooCommerce store, or a membership site with user accounts, WordPress or a proper CMS still makes sense. We still build and maintain WordPress sites for clients who genuinely need dynamic content management.
But for the large category of sites that are essentially digital business cards — landing pages, portfolio sites, brochure sites, "coming soon" pages, institutional informational sites — WordPress was always overkill. We used it because we knew it, because clients asked for it, and because the alternatives required more upfront technical investment than the project budget justified.
That calculation has changed. The upfront technical investment is no longer a barrier. Building a clean, fast, secure static site is now genuinely easier than configuring WordPress to behave like one.
The Bigger Picture
What I'm really describing is a shift in what "web development" means for a solo practitioner or small agency in 2025.
AI-assisted development doesn't replace expertise — it amplifies it. I still need to understand the full stack. The difference is that the execution overhead has collapsed. What used to justify a multi-day project timeline now happens in an afternoon. What used to require a team now works with a single practitioner and an AI agent that handles the repetitive execution while I focus on architecture, security, and client requirements.
WordPress gave me a framework that abstracted away complexity at the cost of control, performance, and ongoing fees. What I have now is a workflow that handles complexity directly, at dramatically lower cost, with results I can fully understand and maintain.
Ten years in, I finally feel like I own my stack again.
The Practical Takeaway
If you're a web professional sitting on a portfolio of simple WordPress sites, each costing you time and money to maintain, here's what I'd suggest:
- Audit your portfolio. Identify sites that are essentially static — no user accounts, no e-commerce, no dynamic content. You'll probably find more than you expect.
- Start with one. Pick the simplest site in your portfolio and migrate it. The process will teach you more than any tutorial.
- Get the security right. A static site without proper security headers is just a different kind of negligent. Do it properly or don't do it.
- Be honest with clients. Explain the trade-offs. Some will value the cost savings and performance. Some will want the WordPress admin panel regardless. Both are valid.
- Don't throw away WordPress knowledge. Understanding WordPress deeply is still valuable — especially when clients need it. This isn't about ideology. It's about choosing the right tool for the actual problem.
Considering migrating your web properties from WordPress to a leaner, faster, more secure stack? IWH helps organisations evaluate their web infrastructure, implement security-first static deployments, and maintain WordPress sites that genuinely need to stay on WordPress. Let's talk about what makes sense for your situation.