What should your website actually be built on
Almost every conversation about a new website starts with a platform question, and almost every platform conversation is really a question about who maintains the site afterwards.
WordPress, Joomla, WooCommerce, Shopify, or something written from scratch. The right answer depends on three things. Whether you want to edit the site yourself, whether you are selling products, and whether the site has to talk to systems you already run.
This is how we think about it when a client asks.
Start with the tool you should use regardless
Before any platform decision, learn what Google thinks of the site you have.
PageSpeed Insights is free, needs no account, and tells you two things in one report. What a real browser experiences on the page (the field data, from people who actually visited), and what a simulated test predicts (the lab data). The field data is the one that matters, because it is measured from your visitors rather than from a test server in a data centre.
It scores against the three Core Web Vitals. LCP is how long the largest element takes to appear. CLS is how much the page shifts around while loading. INP is how quickly the page responds to a click or a tap. Those three replaced the older set, and any article still talking about First Input Delay is out of date.
Run your site through it before you do anything else. If the field data section is empty, that usually means not enough traffic has been recorded yet, and you should test a competitor’s site in the same market for a baseline.
The platform options, honestly
WordPress
WordPress runs 39.2 percent of all websites, which is 57.9 percent of the sites that use a content management system at all, according to W3Techs. That size is the argument for it and the argument against it.
In favour. You can always find someone to work on it. The ecosystem is enormous, themes and plugins cover almost every requirement, and the admin interface is familiar enough that most people can publish without training.
Against. All that third-party code is where the problems come from. A site with twelve plugins has twelve additional things to keep updated and twelve additional ways in. WordPress sites are a common target precisely because they are common, and an unmaintained installation is a liability rather than an asset.
The honest summary is that WordPress is a good default and a poor automatic choice. It rewards maintenance.
Joomla
Joomla sits in the same category, multi-purpose and content managed, with a smaller ecosystem and a smaller pool of developers who know it well.
Choosing it today is reasonable if you already have a Joomla site, a team that knows it, or an extension that does something specific you cannot source elsewhere. Choosing it for a new site with no existing investment is harder to justify, not because it is worse, but because the support pool and the hiring pool are both thinner.
WooCommerce
If you want a store and you want to own it, WooCommerce is the common answer. It is a plugin for WordPress, so it inherits everything above.
In favour. You own the data and the hosting. You control how it looks and how it behaves. There is no platform taking a percentage of each sale, and no platform telling you a checkout customisation is not possible.
Against. You own the maintenance. Payment gateways, shipping rules, tax, plugin updates, security patching and backups all become your responsibility, whether you do them or pay someone. A WooCommerce store is a small piece of infrastructure, not a website with a cart bolted on.
There are alternatives in the same family, such as a hosted store platform that still gives you the codebase. They suit people who want ownership without building everything.
Shopify and hosted stores
If you want to add products, take payments and not think about servers, a hosted platform is the pragmatic answer. Shopify is the best known, and it is where 5.4 percent of all sites are hosted yet its share of the CMS market is far smaller than WordPress, which tells you a great deal about what it is and is not for.
In favour. Hosting, security, uptime and upgrades are someone else’s problem. You get a working store quickly.
Against. You are renting. Monthly cost scales with revenue, the platform takes its cut through transaction fees depending on the plan, and there is a ceiling on how far you can customise before you are fighting the platform rather than using it. Leaving is possible but not free.
A bespoke build
Sometimes none of the above is right, and the site should be written for the job rather than assembled from parts.
That makes sense when the site has to integrate with systems you already run, and those systems expose an API. Stock levels from a warehouse system, pricing from a product database, availability from a scheduling system, customer records from a CRM. WordPress can do this through the REST API and plenty of plugins, and often it is the sensible route. A bespoke build does the same work without carrying code that exists for people who needed something else.
In favour. It is fast, because nothing is loaded that the page does not use. It is light, for the same reason. It is secure by construction, in that there is no plugin layer to keep patched and no third-party module with its own history of vulnerabilities. And it can be as powerful as the integration requires, because you are writing the integration rather than finding a plugin that nearly matches.
Against. You need someone who can maintain it. That is a real cost and it should be faced honestly. A bespoke site maintained by nobody becomes a liability more slowly than a neglected WordPress site, but it still becomes one.
The other thing a bespoke build is bad at is self-service. If you want to add a page, change a heading and publish a photograph on a Tuesday without a developer, a bespoke site gives you no way to do that unless someone builds it. That is often where the decision actually turns.
What a bespoke build actually looks like
It is worth being concrete, because the phrase means different things to different people.
A bespoke site is pages written in code that does only what the page needs. There is no admin panel loading a library of features nobody switched on, no plugin queue, no theme framework deciding how a heading renders. When a visitor loads the page, the browser receives the markup, one stylesheet and whatever script the page actually uses. Nothing else.
The speed difference is not a matter of tuning. On a typical WordPress install, much of what arrives in the browser is there because the platform thought someone might want it. A bespoke build has no such passengers.

Integration is the other half. If your billing system, your stock control or your provisioning platform exposes an API, a bespoke site can call it directly. The page shows live stock because it asks for live stock, not because a plugin synchronises a copy of it every hour.
The costs are real too. Every feature is a build rather than a setting, which means a change you would make yourself on a CMS becomes a ticket to a developer. And a bespoke site needs someone to maintain it who understands the code, because there is no community forum to search when it breaks.
None of that makes it worse. It makes it a different trade.
The question that decides it
Work through these in order.
Do you want to publish and edit content yourself? If yes, a CMS. If no, and the site is a brochure that changes twice a year, a bespoke build or even a static site is honestly simpler and faster.
Are you selling products? If yes, decide between owning the store and renting one. Owning means WooCommerce or a hosted platform that still gives you the code, plus the maintenance. Renting means Shopify or similar, with less control and a recurring cost.
Does the site need to talk to systems you already run? And do those systems have an API. If yes, a bespoke build earns its place. If the answer is “our warehouse system has no API”, a bespoke build cannot fix that, and the work is integration either way.
Who maintains it next year? This is the one people skip and it is the one that causes the most expensive mistakes. A platform nobody on your side understands is a platform you will pay someone else to rescue.
What we would tell you
Most small businesses should be on WordPress, maintained properly, with as few plugins as the job allows.
If you are selling and you want to own the store, WooCommerce is a reasonable default and the alternative is a real choice rather than a small variant.
If you are selling and you do not want to think about it, a hosted platform is not a compromise, it is the correct answer for that requirement.
If your site has to run the business rather than describe it, and you have APIs to work with, a bespoke build is worth the cost. It will be faster and lighter than anything you can assemble, and it will not gain a new attack surface every time someone installs an extension.
We build websites, and we can build yours. That covers a basic WordPress site, a WordPress site with WooCommerce underneath it if you are selling, and the custom built one when the site has to run the business rather than describe it. The custom work is done with our partner, so you are not handing a complex integration to whoever answered the phone.
We build basic WordPress sites, WordPress sites with WooCommerce underneath them, and the custom build when the site has to run the business rather than describe it. The custom work is done with our partner.
Our web development page covers what that looks like. That includes forms, maps, stock, billing and ordering, plus custom tools that make your clients’ interactions easier. If there is a way to integrate through an MCP or an API, or you want a custom tool or system built for internal or external use, that is a conversation worth having. Send us a message.