How to choose the right website platform
Choose the platform based on who will manage the website, what it needs to do and how the organisation expects it to grow, not simply on what the designer, developer or agency prefers to build with.
A website is a long-term business asset, not just a collection of designed pages. The platform behind it shapes how the site is built, edited, extended, secured and maintained long after launch.
Choosing the right CMS or website builder is therefore less about “which tool is best” and more about “which tool fits the way this organisation will actually use the website.”
In my experience, the right platform is the one that creates the best balance of:
- Control (what the team can change safely)
- Flexibility (how the site can evolve)
- Performance (speed, stability, SEO basics)
- Cost (build + ongoing running costs)
- Maintainability (how easy it is to keep healthy over time)
Platform recommendations often begin in the wrong place
Every designer, developer and agency has preferred tools.
Some specialise in WordPress. Others work mainly with Webflow, Framer, Shopify or another platform. Some prefer headless systems or custom development.
There is nothing wrong with specialisation. Deep knowledge of a platform can lead to stronger implementation and better quality control.
The problem begins when familiarity is mistaken for suitability.
If an agency has a team of WordPress developers, WordPress can become the default answer. If its process is built around Webflow, every project may be framed as a Webflow project. A developer who prefers custom builds may prioritise technical control even when the client needs a straightforward editing experience.
In each case, the recommendation starts with what the agency knows rather than what the client needs.
This is rarely bad faith. It is natural to recommend tools you understand well. I have preferences too.
But the platform should be selected around the client, not around the production habits of the people building it.
Start with what happens after launch
Platform decisions are often made around the launch date:
- Can the design be built?
- Can the required features be delivered?
- Can the site meet the budget and timeline?
- These questions matter, but they only describe the project before launch.
The more important questions concern what happens afterwards:
- Who will manage the website?
- How often will content be updated?
- What types of pages will be created (articles, case studies, landing pages, products, resources)?
- Which parts should the team be able to change independently?
- What systems must the site connect with (CRM, ecommerce, analytics, booking, marketing automation)?
- How might the business and content strategy evolve over time?
A marketing team publishing several times a week has very different requirements from a small business that updates its website a few times a year. An organisation with an internal development team can operate a different setup from a founder who needs to manage the website independently.
The platform should fit the organisation around the website, not just the website itself.
Flexibility on paper is not the same as control
I have seen websites described as “flexible” because they included a CMS, reusable components and editable content.
Technically, the client could update the website. In practice, almost every meaningful update still required support from the agency.
The content could be edited, but only within a narrow structure. New pages could be created, but they could not use a different layout without development work. Components that appeared flexible had been hard-coded around the original pages rather than designed around the ways the website would need to evolve.
The client had not received a flexible system. They had received a fixed set of pages with an editing interface attached.
This is where “flexibility” can turn into dependency.
There will always be changes that require design or development expertise. Clients should not be expected to build complex functionality themselves, and unrestricted editing can harm consistency as easily as it creates freedom.
But routine changes should remain routine.
Updating copy, publishing an article, adding a case study, replacing an image or creating a page from an existing system should not become a new production project every time.
Match the platform to the type of website
There is no universally best website platform.
Different platforms solve different problems, so the decision should start with the type of website the organisation needs and the people responsible for managing it.
Brand and marketing websites
Brand-led and marketing websites often need strong visual control, responsive design, structured content and an editing experience a marketing team can understand.
Webflow can provide a useful balance across those requirements, particularly when the website needs a distinct visual expression without the maintenance burden of a traditional plugin-based CMS.
Framer can be effective for smaller, design-led sites and fast-moving marketing pages. Squarespace may be more appropriate when simplicity, speed and low technical overhead matter more than extensive customisation.
The right choice depends on the content model, the expected lifespan of the website and how much control the team needs after launch.
Content-led websites
Organisations publishing large volumes of content may need stronger workflows, permissions, categorisation, localisation and relationships between different types of content.
WordPress can be a strong option when the organisation already has experience with it or when its publishing requirements are well served by the wider ecosystem. HubSpot CMS may make sense for a business whose website is closely connected to its CRM, lead generation and marketing automation.
More demanding governance or multilingual requirements may justify Drupal or a headless CMS such as Contentful or DatoCMS.
These systems can offer significant capability, but that capability also brings more implementation and maintenance work. They should be chosen because the organisation needs their strengths, not simply because they are more technically powerful.
Commerce websites
If selling products, managing inventory, processing payments and connecting commerce tools are central to the business, the platform should be designed around commerce from the beginning.
Shopify is often a more appropriate foundation than trying to turn a general-purpose CMS or website builder into a complete commerce operation.
Digital products and custom functionality
Some websites are closer to applications than marketing pages.
They may need user accounts, complex data, specialised interactions or functionality that standard website builders cannot handle well.
In those cases, custom development or a headless architecture may be justified. The additional complexity creates more technical control, but it also creates more responsibility for hosting, maintenance, content management and future development.
A custom-built website should solve a genuine technical or business requirement. It should not introduce complexity simply because the capability exists.
The important question is not which platform is most capable.
It is which platform provides the capabilities the organisation needs without creating unnecessary cost, dependency or complexity.
A quick decision framework (the questions that should come first)
Before recommending a website platform, I want to understand more than how the website should look. These are the questions that usually clarify the direction fastest:
- Purpose: What role does the website play in the business (brand, lead gen, publishing, commerce, product)?
- Ownership: Who will manage it after launch, and what skills do they have?
- Cadence: How often will content be updated, and by whom?
- Content model: What content types matter (pages, articles, case studies, resources, products), and how structured do they need to be?
- Editability: What must be editable without breaking design consistency?
- Workflows: Do approvals, permissions, governance or localisation matter?
- Integrations: Which systems must the website connect with now (and later)?
- Longevity: How likely is the site to need new sections, new page types or a major restructuring over the next 2–3 years?
- Budget reality: What level of hosting, security and maintenance is realistic over time?
- Independence: Where does the client need independence, and where is specialist support still valuable?
These questions do not always lead to the most technically advanced platform.
They lead to the most appropriate one.
A recommendation should explain the trade-offs
There is no perfect CMS or website platform. Every option involves trade-offs around flexibility, performance, maintenance, cost, creative control, integrations, scalability and ease of use.
A responsible recommendation should make those trade-offs visible.
The client should understand not only why a platform is being recommended, but what choosing it will mean over time:
- What can the internal team manage?
- What will still require support?
- How easy will it be to introduce a new content type?
- What happens if the business expands into new markets?
- Will the website remain manageable if the original agency is no longer involved?
“Because this is what we use” is not enough of an answer.
Build for the next chapter
No platform can guarantee that a website will never need to be rebuilt.
Businesses change. Technology moves forward. Strategies evolve, and what a website needs to do five years from now may be impossible to predict today.
The goal is not to choose a platform that lasts forever. It is to avoid unnecessary obsolescence.
Choose the platform around the client. Then design and build the website around what the client needs to achieve.
If you are planning a new website and are unsure which platform or setup is right for your organisation, I can help define the direction before design and development begin.
