Your Small Business Might Not Need WordPress

Early in my career, I worked at an agency in Stockholm where we built WordPress websites for some of our clients. Back then, web development often meant making much more fundamental choices about the technology underneath a website. At university I'd worked with ASP, but I found myself more drawn to PHP - partly because it powered systems such as WordPress, Joomla and Drupal.

What made those platforms exciting wasn't just the technology. It was what you didn't have to build. Instead of creating the plumbing for every website from scratch, you could start with something that had already solved publishing, users, pages, media, administration and a long list of other recurring problems.

Why reinvent the wheel when somebody had already built a pretty good wheel?

As I became a professional developer, that became even more obvious. There's a difference between building something because you're curious about how it works and delivering something when somebody is paying for your time. Time matters. If a solved problem doesn't differentiate the result, solving it again isn't necessarily craftsmanship. Sometimes it's just wasted effort.

So I understand exactly why WordPress became such a popular choice for agencies and businesses. I used it myself, and sometimes I'd still recommend it today.

But I no longer think "website" automatically means "WordPress."

Not:

What’s the most powerful platform we can give this website?

But:

What does this website actually need to do?

Powerful doesn't automatically mean appropriate

WordPress can do an enormous amount. That's one of its greatest strengths. There are plugins and integrations for almost anything you can imagine, a huge developer community, familiar hosting and support, and a good chance that somebody has already solved the functionality you need.

The problem starts when we confuse being able to do something with needing to do it.

Most of the small-business websites I work with don't need to become enormous digital platforms. Their job is usually much simpler: explain what the business does, make it look credible, help the right people find it, make it easy to get in touch, and stay fast, reliable and manageable.

That's already an important job. But it doesn't necessarily require a huge amount of infrastructure.

A small-business website should earn its complexity. Every additional moving part should give the business something valuable in return. If it doesn't, why is it there?

There are still times when WordPress is a very good choice

I've seen WordPress work extremely well. At one agency I worked with, we maintained WordPress websites for large corporate clients. The sites were highly optimized and, once established, much of the ongoing work was simply content publishing and maintenance.

Interestingly, although the clients had access to WordPress themselves, they would often ask the agency to make updates for them. I think that's a good example of technology working as it should: the client could focus on the business while somebody who understood the system handled the website.

I've also used WordPress countless times for blogs and personal projects. That's an area where I still think it shines. You can get a site running quickly, use a familiar administration interface and start publishing without designing an entire editorial system first.

Familiarity matters too. If your team already understands WordPress, switching has a cost. Another developer can usually recognize the system quickly, outside support is easy to find, and hosting companies have built mature support ecosystems around it.

If you publish frequently, have complex editorial workflows, many editors or existing WordPress functionality that already solves important business problems, those are genuine reasons to keep or choose it.

Sometimes I'd recommend WordPress. The technology should fit the requirement - including when that requirement points toward WordPress.

The part I increasingly question is everything around the website

My more recent experience has pushed me in the other direction. I was running several sites through a WordPress multisite setup on Bluehost.

Multisite has advantages: you can manage several websites together and share things such as plugins between them. But it also ties the sites together. Changes in one part of the system can have implications elsewhere, while you're maintaining WordPress itself, the hosting environment, themes, plugins and the relationships between them.

In my case, I started experiencing recurring downtime and slow loading on my own website.

I'm not claiming WordPress itself was necessarily the cause. A WordPress site's performance can be affected by hosting, configuration, themes, plugins, images, caching and how the site has been built. WordPress's own performance guidance makes the same point, listing factors including hosting, configuration, themes, plugins, software versions and image sizes.

A skilled WordPress developer could probably make many slow WordPress websites dramatically better. But at some point I found myself asking a different question:

Why am I spending time optimizing all of these moving parts for a website that doesn't actually need most of them?

That question matters more to me than whether WordPress can technically be made fast. The question is what you needed to build and maintain in order to get there.

Fewer moving parts can be a feature

I eventually rebuilt my own website using Next.js. The resulting site is extremely fast in my own testing, and from the public website's perspective the architecture is considerably leaner.

If you want to see what I mean in practice, take a look at jacobwestman.com. In the Lighthouse snapshot shown below, the site scored 100 for Performance. That doesn't prove custom sites are always faster than WordPress; it's simply an example of what a very lean public-facing setup can achieve.

But I also gave something up. I no longer had WordPress sitting behind the website with its familiar administration interface, so content changes became more manual.

That's a genuine trade-off. If I stopped the argument there, it would simply become another technology preference: WordPress versus Next.js. That's not really the point.

Today the choice isn't WordPress or no content management system. There are other ways to separate the experience used to manage content from the technology used to deliver the public website.

For example, Myrmidon can use a content platform such as Sanity to give a client the fields and editing functionality they actually need while keeping the public website relatively lean. Instead of adopting an entire system and then removing or working around the parts we don't need, we can increasingly build the editing experience around the business.

That still means we're using solved infrastructure. We're not reinventing the wheel. We're just choosing a smaller wheel.

Custom-built doesn't automatically mean better either

There's another side to this that custom developers sometimes conveniently forget: a badly built custom website can be a nightmare.

Just because something is bespoke doesn't mean it's maintainable, fast or well engineered. A developer can create unnecessary complexity without using a single WordPress plugin.

If your entire website depends on one developer who built an unusual system nobody else understands, you've exchanged one form of dependency for another. That's a legitimate risk, and one of the reasons established ecosystems such as WordPress remain attractive.

The answer isn't "custom is better." It's to make the system understandable, maintainable and proportionate to the job it needs to do.

What has changed for custom development

Where I do think the equation has shifted is in how difficult custom software is to build, understand and maintain.

Five or ten years ago, one of my concerns with a custom website would have been what happens when another developer needs to take over. I wrote a little more about that earlier chapter in Meet Myrmidon: The Story So Far.

That concern hasn't disappeared, but from my perspective as a developer it has become smaller. Modern frameworks, automated testing, documentation and AI-assisted tooling give us better ways to describe and protect how a codebase should work.

At Myrmidon, for example, we can ship configuration and instructions that describe how a project is structured, what conventions apply and how AI-assisted tools should work with it. Tests can help the next developer see whether a change has broken expected behaviour. That's a very different handover from an undocumented custom site that only one person understands.

At the same time, WordPress still has an extraordinary scale advantage. As of September 2026, W3Techs estimates that WordPress powers about 40% of all websites and roughly 59% of websites whose content management system it can identify.

I don't think WordPress disappears. I do think the reasons that made an integrated CMS such an obvious default are changing. Content systems can be separated from the public website, hosting and deployment are easier, testing is better, and custom interfaces are faster to build than they used to be.

That means choosing WordPress merely because "that's what websites are built with" makes less sense to me than it once did. The platform should earn its place just like everything else.

So, should your business use WordPress?

Possibly. I would start with the business rather than the platform.

If you already have a WordPress website that performs well, your team understands it, the editing experience works and the ecosystem solves real requirements for you, there may be very little reason to replace it.

Don't rebuild technology for the sake of rebuilding technology.

If you're wondering whether your website actually needs a redesign, we covered that in 5 Signs Your Small Business Website Needs a Redesign.

But if your website is relatively simple and you mainly need it to explain your business, establish trust, get found and generate enquiries, I'd ask a different set of questions:

• What does WordPress give you that you genuinely use?
• Who maintains it?
• Which parts of the system are essential?
• What happens if you remove them?
• How much ongoing work exists simply because of the architecture you chose?
• If you were starting again today, would you choose the same system?

There isn't one universally correct answer. But there should be a reason for the answer you choose.

Your website should earn its complexity

I've gone from seeing WordPress as an incredibly convenient solution to seeing it as one solution among many. That isn't because I've forgotten why it became popular. Quite the opposite.

I've used it long enough to understand why people like it. I've built with it, used its ecosystem and benefited from the convenience. I've also experienced the other side: the dependencies, the maintenance and the feeling that I was carrying more moving parts than the job actually required.

That experience is part of why Myrmidon takes a leaner approach today - not because custom code is automatically superior, but because I think technology should justify itself through what it does for the business.

For a small-business website, more isn't automatically better. Sometimes the better system is the one that does exactly what you need - and very little else.