Why I stopped building WordPress sites

I built WordPress sites for years.

I knew WordPress well. I had a stack I trusted: Kadence theme, ACF, a child theme I had refined over dozens of projects. I could build a solid site quickly. Clients were happy. It worked.

Then I stopped.

Not because WordPress is bad. It is genuinely powerful, and for the right use case, it is still the right tool. But for the small service businesses I work with (coaches, wellness practitioners, consultants, therapists), I came to believe it was the wrong fit. And the reason it took me this long to say that out loud is that the problems were easy to ignore until they weren’t.

The maintenance problem.

WordPress sites require maintenance. Not occasionally. Constantly.

Plugins need updating. Themes need updating. PHP versions need updating. And every update is a small risk. Most go fine. Occasionally one breaks something. When it breaks something on a client’s site and I’m the one who ran the update, I’m the one dealing with it.

For a (mostly) solo operator running care plans for multiple clients, this is a lot of overhead. I was spending meaningful hours every month on maintenance tasks that produced no visible value for the client. From the outside, their site looked exactly the same before and after. The work was invisible, necessary, but relentless.

Static sites don’t have this problem. There is no database to exploit, no plugins to update, no PHP version to manage. The security surface is dramatically smaller. A well-built static site mostly just runs.

The security problem.

WordPress is the most targeted CMS on the internet. That is not a criticism. It’s a consequence of market share. When you build the majority of the web, you become the majority of the attack surface.

For most small businesses, the actual risk is low. But the anxiety is real. I had clients who got phishing emails claiming their WordPress site had been compromised. Sometimes it was spam. Sometimes it wasn’t. Either way, someone had to investigate, and that someone was me.

I started to notice that a significant portion of my client support time was not about helping clients move forward. It was about defending against problems that a different technical choice would have largely prevented.

The performance problem.

WordPress sites can be fast. With the right host, the right caching configuration, a well-optimized theme, and disciplined plugin management, you can score well on Core Web Vitals.

But that requires ongoing attention. Add one poorly-coded plugin and your Lighthouse score drops. Change hosts and the caching configuration needs to be rebuilt. Clients install plugins without telling me and suddenly the site is slow again.

A static site is fast by default. There is no server-side rendering, no database queries, no plugin overhead. The HTML is generated at build time and served directly. You start fast and stay fast without active management.

The ownership problem.

Here is the one that bothered me most.

A WordPress site looks like something a client owns. They have an admin login. They can log in and poke around. But in practice, most of my clients had no idea how their site worked, couldn’t make changes without risking something, and were dependent on me for anything beyond the most basic edits.

That’s not a criticism of them. Running a coaching practice, therapy office or any small service business is a full-time job. Learning WordPress is not a reasonable ask on top of that.

But the WordPress ecosystem is built around the assumption that someone is actively managing it. The owner, the designer, someone. When the real answer is “nobody is,” the site drifts.

With a static site, I’m honest about the arrangement from the start. The client does not have a CMS to learn. They have me. Changes go through the care plan. The site stays accurate and maintained because that’s what I do, not because I’m hoping the client logs in.

What I’ve switched to.

I now build with Astro and Tailwind. Static output, no database, no server-side platform.

For small service businesses, the coaches, practitioners, consultants, and local service providers I work with, this stack is a better fit. Pages load in under a second. Security overhead is minimal. Maintenance is honest and scoped.

The tradeoff is that Astro sites aren’t self-editable by the client in the way a WordPress site can be. But for the clients I work with, that was never the real value anyway. The value was always having someone who handles it. So I made the arrangement explicit instead of pretending otherwise.

What this means for you.

If you’re a small service business owner evaluating a new website, here is the honest version of this:

A WordPress site can be a fine choice. If you have a developer you trust who will actively maintain it, and if you need features that require a CMS, it may be exactly right.

But if what you actually want is a fast, secure site with low ongoing overhead and a real person handling the maintenance, without the illusion that you’ll manage it yourself someday, a static site built for that purpose is the better call.

That is what I build now. And my clients’ sites are faster, more secure, and less work for everyone as a result.

Book a 15-minute call and we’ll figure out what makes sense for your site.

---

Curious what a Bewebsy build actually looks like? Read what a one-day website build is for the process, what’s included, and how it works from start to finish.