The invoice hit my inbox: €35. About $41 a month, nearly $500 a year.
Six years ago, Hardypress was exactly what I needed. I was drowning in WordPress maintenance—hacked sites, plugin updates, theme conflicts—and Hardypress promised static site security and speed without abandoning WordPress entirely. It solved real problems. I was grateful for it.
But a lot changes in six years. And that invoice made me ask a question I’d been avoiding: is this still the right tool for where I am now?
It wasn’t. I moved all my WordPress sites to Hugo and Netlify. Each took about a day. I’m not looking back.
The WordPress Years
I don’t need to convince most people that WordPress is exhausting. If you’ve run a WordPress site for any length of time, you already know.
I know it better than most. I spent years running product and marketing for Wordfence, the dominant player in WordPress security. I built their Attack Analytics platform. I started their site cleaning business. I’ve seen what happens when WordPress sites get hacked—from the inside, at scale. The constant updates, the plugin vulnerabilities, the security anxiety—I understood exactly why it all existed.
And I was still tired of it.
The constant updates. Core, plugins, themes—always something needs patching. The security anxiety, even knowing what I know. The plugin decision fatigue. Do I really need this feature? Is this plugin maintained? Will it conflict with something else? The theme updates that break things. The multi-layered troubleshooting where you can’t tell if the problem is your code, an unrelated plugin, or the theme itself.
And page builder bloat. Don’t get me started on page builder bloat.
The final insult is Gutenberg, WordPress’s block editor. A disaster they continue to cling to. Every time I opened that editor, I felt my energy drain. This is the flagship editing experience for 40% of the web, and it’s genuinely unpleasant to use.
I was done. I wanted out.
The Hardypress Detour
Hardypress seemed like the answer. It’s a service that takes your WordPress site and outputs static files. You get the security benefits of static hosting—no database to hack, no PHP vulnerabilities to exploit—plus the speed of serving flat HTML from a CDN. But you keep WordPress as your editing environment.
For a while, this was great. My sites were fast and secure. I stopped worrying about getting hacked. The core promise delivered.
But here’s what I didn’t fully appreciate at the time: Hardypress is still WordPress.
I was still using Gutenberg. Still making plugin decisions. Still dealing with theme headaches. I’d solved the output problem—static files, served fast—but I hadn’t solved the input problem. I was still managing WordPress. Just with extra steps.
And those extra steps added their own friction. The WordPress instance has to boot before you can edit anything. That takes time. If you get distracted and step away, the instance shuts off. Now you’re booting it again. Publishing isn’t instant—you’re waiting for the static site to regenerate. And support, while genuinely excellent, is one guy in Europe. Great response times in his morning, less so in my late afternoon.
None of this was dealbreaking on its own. But it accumulated. Six years of small friction, adding up.
That €35 invoice was the moment I finally did the math. Nearly $500 a year for a workflow that fought me at every turn. For something that still made me use Gutenberg.
Meanwhile, the world had moved on.
What Changed
Three things shifted while I was tolerating Hardypress.
AI-native development tools matured. Cursor and similar tools have transformed how I work. I can describe what I want, watch the AI implement it, catch its mistakes, push to git, and I’m done. But that workflow requires a codebase the AI can understand. WordPress—with its database, its plugin architecture, its theme hierarchy—is opaque to these tools. A static site built with Hugo is completely legible. Every file is right there. The AI can see it, modify it, reason about it.
Git-based CMS options got good. Decap CMS (formerly Netlify CMS) gives you a clean editing interface for content, backed by git. No database. No server. Just markdown files in a repository, with a friendly UI on top. As Decap’s documentation puts it, you get “robust versioning and history capability” where you can “restore exact states from any point in history.” Setup takes two files.
Free hosting became genuinely free. Netlify’s free tier handles everything I need. Not “free with asterisks.” Actually free.
The modern stack—Hugo for static site generation, Netlify for hosting, Decap for content editing, Bootstrap and custom CSS for styling—delivers everything Hardypress promised, without WordPress in the middle. And it costs nothing.
If you’re curious about the broader WordPress-to-static landscape, I wrote about using WordPress as a CMS for static websites earlier this year, covering different approaches including Hardypress.
The Move
I moved all my sites off Hardypress, each in about a day. Could have been faster, but I made improvements along the way—cleaned up structure, tightened the design. The kind of work that would have been a multi-day slog in WordPress.
The benefits I’d gotten from Hardypress came along for the ride. Security? Static sites have no attack surface. Speed? Netlify claims that “a normal static site hosted on a CDN is often 10 times faster time-to-first-byte than a site built with a legacy CMS.” Resilience? If one CDN node gets hit with a DDoS attack, your site just gets served from the next closest node. Visitors never notice.
But the new benefits are what changed my daily experience.
No WordPress bloat. No plugins, no themes, no Gutenberg. Just markdown and HTML. CloudCannon notes that Hugo ships with built-in templates for SEO, analytics, and commenting—“unlimited content types, taxonomies, menus, and dynamic API-driven content, all without plugins.”
Instant publishing. No boot times. No waiting for a WordPress instance to spin up. No publishing spinner. I push to git and the site is live in seconds.
Full design control. Bootstrap for structure, custom CSS for everything else. No page builder limitations. No theme constraints. I control every pixel, and the code is clean enough that I can actually maintain it.
AI-friendly. This is the big one. My entire workflow now fits the way I want to work. I open Cursor, make a change, preview it locally, push to git, and I’m done. The AI can see the whole codebase. It can make suggestions. It can implement changes. I watch what it does, catch its mistakes, and move on. So. Easy.
Free. My hosting bill went from nearly $500 a year to zero.
The Honest Trade-Off
I’m not going to pretend this is for everyone. The downside is real.
There’s no page builder. No friendly admin panel for layout changes. If you want to edit the structure of your site, you need to be comfortable with code—or comfortable supervising an AI that writes code.
And that “supervising AI” part is non-trivial. Tools like Cursor are powerful, but they require a specific skill set. You need to know how to prompt effectively. You need to watch what the AI actually does, because it will lie to you. It will write bad code. It will delete things without telling you. If you don’t know how to ask right, watch closely, and call it out on its bad behavior, you’ll make a mess.
For a non-technical user, the learning curve is steep. You’re not just learning one tool. You’re learning a stack: a code editor (Cursor or VS Code), version control (git, GitHub), and AI supervision. Each piece is learnable, but together they’re a significant lift.
There’s a middle ground, in theory. You could architect the site so that non-technical users edit content through Decap while the structure stays locked down. Map specific fields to specific components. Give them a clean UI for the things they’re allowed to touch.
But this requires real forethought. You have to plan it upfront. It’s painful to retrofit after the fact. And you’re taking Hugo’s greatest strength—flexibility, full control, change anything anytime—and deliberately constraining it. You end up maintaining a rigid system that fights against the tool’s nature. Every “can you just add a new section?” request means a developer gets involved anyway.
WordPress, for all its sins, solved this problem by making everything editable by everyone. That’s also why it’s a bloated, hackable, plugin-dependent mess. The trade-off is real.
Who This Is Actually For
This stack is perfect for me. I run Pike and Vine. I’m technical. I want full control and minimal friction. I open Cursor, make a change, check it in dev, push to git, and I’m done. That’s my entire publishing workflow now.
It’s also great for my brother’s painting business site. He goes literally years without updating site content. His only regular updates are blog posts, and Decap handles those beautifully. When he needs structural changes—which is rare—I handle them. That works because it’s rare.
Two very different use cases, same stack, both working well.
It’s not for everyone.
If you’re non-technical and need to make frequent structural changes, this isn’t your path. If you’re building sites for clients who expect WordPress-style “I can edit anything myself” autonomy, think carefully. If you don’t have developer access for ongoing maintenance, the flexibility becomes a liability.
The question isn’t “Is Hugo better than WordPress?” It’s: what’s your editing pattern, and who’s doing the work?
One More Thing
I’ll add a note that wouldn’t have mattered to me six years ago but matters now.
The WordPress ecosystem has gotten weird. The ongoing legal battle between Automattic and WP Engine has rattled a lot of people. Plugin access getting cut off. Governance questions. Drama.
One developer put it simply: “There is enough drama in the world right now. I don’t need to also worry about whether or not my website host, or the plugins I rely on, will become targets. I prefer to work with a stable, welcoming platform.”
I’m not leaving WordPress because of the drama. I left because the tool no longer fit my needs. But the drama reinforced something I already felt: I don’t want my infrastructure dependent on an ecosystem I can’t control.
Hugo is just files. Netlify is just hosting. Git is just version control. There’s no platform politics. No dependency on someone else’s business decisions. Just my code, my content, my site.
That feels right.
The Bottom Line
Six years ago, Hardypress was the right call. It got me out of the worst of WordPress’s security and performance problems without requiring me to learn a new stack.
But the stack has gotten better. The tools have gotten smarter. And I’ve gotten clearer about how I want to work.
If you’re technical, if you want full control, if you’re tired of waiting for WordPress instances to boot, if you’re done with Gutenberg, if the phrase “push to git and you’re done” sounds like freedom—this might be your move too.
One day per site to migrate. Zero hosting cost. A workflow that actually fits how I think.
I should have done this years ago.
Sources and Further Reading
The Top Five Static Site Generators for 2025 CloudCannon Comprehensive overview of Hugo, Eleventy, and other static site generators, with practical guidance on when to use each.
9 Reasons Your Site Should Be Static Netlify The case for static sites: performance (10x faster TTFB than legacy CMS), security, reliability, and cost efficiency.
Why I Switched to Hugo Tread Lightly A developer’s firsthand account of leaving WordPress for Hugo, including honest discussion of the trade-offs and the WordPress ecosystem concerns that influenced the decision.
Git-Based CMS: Definition, Features, Best Practices Decap CMS Deep dive into how git-based content management works, including versioning benefits, setup simplicity, and scaling considerations.
The WordPress vs. WP Engine Drama, Explained TechCrunch Overview of the ongoing legal battle between Automattic and WP Engine that has raised governance questions across the WordPress ecosystem.