The most expensive sentence in a web project is “we’ve decided to use X.” Platforms aren’t interchangeable, and the differences that matter aren’t the ones on comparison charts.

The most expensive sentence in a web project is “we’ve decided to use X.” Not because X is necessarily wrong — but because the decision was made before anyone established what the business actually needs it to do.

Platforms are not interchangeable, and the differences that matter aren’t the ones on comparison charts.

What each platform is genuinely good at

It’s worth being concrete, because the honest version is more useful than the marketing version.

WordPress

Strong when the site is primarily content that changes — services, articles, pages, team members — and when the client wants to edit that content themselves without calling a developer. The plugin ecosystem covers most standard needs. Its weakness is that the same flexibility lets a site accumulate plugins until it’s slow and fragile, and long-term maintenance is real work.

Shopify

Strong when selling physical products is the core of the business and the catalogue is manageable. It handles the hard parts — payments, tax, shipping, inventory — so you don’t build them. Its weakness is that highly custom logic, unusual product configuration, or content-heavy marketing alongside the store can run into the edges of what it wants to do.

WooCommerce

Strong when commerce is part of a broader content site, or when you need tighter control over how products and checkout behave than a hosted platform allows. The trade-off is that you own more of the infrastructure and the maintenance that comes with it.

Custom application

Strong when the thing you need isn’t really a website — a portal, a quoting tool, an internal dashboard, a workflow that no existing product models. This is the option to reach for when you’ve established that the process is genuinely unusual, not when you want something bespoke for its own sake.

The pattern

Each option optimises for something different: ease of editing, commerce infrastructure, control, or fit with an unusual process. You can’t have all four, so the question is which one your business actually needs most.

The questions we ask first

Before recommending anything, we want answers to these. They’re not technical questions, which is precisely the point:

• Who will update this day to day, and how comfortable are they with software?
• What changes most often — content, products, prices, or structure?
• What has to connect to it? Payments, CRM, inventory, booking, accounting.
• How unusual is the process it needs to support? Is there an existing product that models it closely, or are we describing something genuinely custom?
• What’s the realistic budget for ongoing maintenance, not just the initial build?
• Where does this need to be in three years — is it likely to grow in the direction the platform handles well?

The answers usually make the decision obvious. When they don’t, it’s usually because one requirement is genuinely unusual — and that’s the requirement worth designing around.

Why choosing first is expensive

When the platform is fixed before the requirements are known, one of two things happens. Either the project quietly works around the platform’s limits — adding plugins, custom code, and complexity to force a fit — or it reaches a point where the mismatch can’t be worked around and the work has to be redone.

The first outcome is more common and more insidious. Nothing fails outright. The site just gets slower, harder to maintain, and more expensive to change, until someone eventually asks why a simple update takes three weeks.

A platform is a set of trade-offs. Choosing it before you know which trade-offs you can live with is how you end up living with the wrong ones.

When we’d tell you not to change anything

Sometimes the audit concludes that the platform you’re on is the right one and the problem lies elsewhere — in how the site is structured, how it’s hosted, or what content it carries.

That’s a genuinely useful outcome. Migrating platforms is disruptive and expensive, and doing it to solve a problem that a migration won’t fix is one of the more avoidable ways to spend money.