Ideas & practical guidance

Website insights

Choosing a website means choosing how your team will publish information, how customers will use it and who will look after it. Use these guides to compare those everyday tasks before settling on a platform.

Let’s talk

Decisions worth making clearly

When you compare website proposals, the platform name can draw attention away from the work the site needs to do. Who will update a service page? What must a customer be able to complete? Who will deal with a failed connection or a change after launch?

We use those questions to make the technology discussion more useful. The guides in this collection help you compare an approach against your publishing, customer and maintenance needs, and explain why it fits.

In this collection

Put the guidance to work

Choose one task from your own business before reading the comparison. For example, take a service description your team updates regularly and follow it from the first draft to the published page. Note who supplies the information, who approves it and who makes the change. Then describe what a customer should do after reading it.

Bring that example, your current content and any unresolved requirements to a scope discussion. We can use them to identify what needs investigation before recommending an approach. An article can help you ask better questions; a project decision still needs a close look at your requirements.

Explore the related service or discuss your brief with the goals, constraints and responsibilities you need to resolve.

Separate publishing needs from application behaviour

Publishing a service page and applying a business rule are different requirements. In a hypothetical enquiry process, an editor might need to change the service description, while the site might also need to send an enquiry to the right destination based on a customer’s selection. Describe both tasks: an easy editing experience alone does not explain how the enquiry rule will work.

For each task, ask who performs it, what information they need and what happens when something changes. Which parts can use an established approach, and which need specific logic? This gives you a clearer basis for comparing platforms than a general preference for WordPress or custom development.

Choose a platform question with a concrete example

Ask an editor to demonstrate a representative content change. Can they replace the text, check the result and get it approved through the proposed workflow? Ask a technical reviewer to walk through a business rule or integration with the same care, including what happens if required information is missing.

Use the answers to compare the proposed CMS or application. Alongside the demonstration, ask who supplies the content, checks accessibility, provides support and approves releases. A platform choice leaves each of those jobs to be agreed.

Compare WordPress and custom PHP · Explore website services · Discuss the publishing task.

Website-planning FAQs

A few useful answers before you decide.

Should I choose WordPress before writing the brief?
Describe the editing and customer tasks first, then assess the fit. You can include WordPress as an option in the brief without making it a requirement. Ask each proposal to show how the approach supports your routine updates, any specific business rules and the people who will maintain it. That makes the recommendation easier to assess than a platform name on its own.
Does custom PHP mean the whole site must be bespoke?
Not necessarily. A project may combine established components with specific application behaviour. Ask the proposal to identify which parts need custom logic, why they need it and who will maintain them. Compare future changes and ownership alongside the initial build; the word “bespoke” does not establish quality or tell you which option will cost less to run.
What should editors help decide?
Ask them to demonstrate routine updates, approval needs and material they find difficult to maintain. A useful example is a service-page change that needs another person’s approval before publication. Walk through who can edit, who can approve and how they check the finished page. That helps establish the content patterns and access roles the team actually needs, including which changes should be possible without asking a developer.
How do integrations affect the platform choice?
List the systems involved, who controls the data and which interfaces are available. Then follow a specific piece of information through the proposed connection: where does it start, where should it arrive and who checks a failure? A possible connection still needs checking against your actual account and workflow. Establish access and responsibility before relying on an integration as a reason to choose a platform.
How should maintenance enter the decision?
Ask for the ongoing tasks and costs alongside the build proposal. Updates, subscriptions, backups, content changes and release checks all need someone responsible for them. For each task, establish whether your team, the build supplier or another provider will handle it, and what is included in the proposed arrangement. That gives you a more useful comparison of ownership costs than the launch price alone.
What should our decision record contain?
Keep a short explanation of the selected approach, the needs it serves, the alternatives considered and the trade-offs you accepted. Include any assumption that could change the choice and who can revisit it. For example, if the recommendation depends on editors being able to manage routine service-page changes, keep that requirement in the record. Future editors and developers can then understand what the platform was chosen to support.
Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk