Guide / choosing technology
WordPress or a custom build?
This comes up in almost every first conversation. The answer is not "always this" or "always that" — it depends on how often you will change content, who will do it, and how long the site should live without a rebuild.
On this page
When a ready-made system makes sense
If you plan to add content regularly — posts, news, new service pages — and want to do it yourself, a content management system pays for itself quickly. It also makes sense when you need common features somebody has already solved well: forms, a calendar, a simple catalogue.
When it starts getting in the way
Trouble starts when a simple brochure site accumulates fifteen plugins, each adding to load time and each being another thing to update. The site that was meant to be cheap to run becomes the most expensive part of company IT.
The second warning sign: the site looks like a template because it is one. If your advantage is doing something differently from competitors, a site identical to theirs works against you.
Questions worth asking before deciding
- How often will I really change content — weekly, quarterly, once a year?
- Who will do it: me, someone in the company, or the developer as part of care?
- Do I need features, or just a well-told offer?
- What happens if I want to change developer in two years — do I take the content and URLs with me?
The most common mistake
Choosing technology before establishing why the site should exist. A "we'll build it on X" decision made in the first meeting usually means fitting needs to the tool rather than the other way round. Content and goal first, tool second.
Put it into practice
Start with how you will use it
WordPress and a custom build can both be suitable. Compare what you will actually use after launch.
| Need | WordPress / existing CMS | Custom solution |
|---|---|---|
| Regular publishing | An existing editor and publishing tools; keep the add-on set deliberate. | Editing needs to be scoped and designed around the content that changes. |
| Common features | A proven extension may shorten delivery; it still needs maintaining. | The feature is built for a particular workflow and quoted separately. |
| A simple, rarely updated offer | Possible, but the editor and update overhead should have a reason. | A light site can reduce the number of parts needing care. |
| Development and portability | You need access, data backups and clarity about extension licences. | You need code, data, deployment instructions and access to the services used. |
Three questions before choosing
Will you regularly publish content yourself?
Yes → start with an editor demonstration and a real publishing task. WordPress or another existing CMS may fit. No → compare a light editor with occasional changes handled through care. Then consider functionality.
Are the features you need conventional?
Yes → check the scope and maintenance of available extensions. No → describe the workflow, integrations and permissions; compare extending a CMS with a custom solution. An unusual visual design alone does not require a bespoke system.
Who will maintain it after launch?
Before deciding, compare updates, licences, access to data, future changes and portability. Choose the option that suits both day-to-day work and your ability to maintain it.
A technology name does not guarantee speed or easy editing. Ask to see a price, photograph or service changed in the proposed editor.
Scope and daily operation come first; the tools follow.
How I choose a website solutionQuestions before we start
Is a custom build always more expensive?
Usually to build, often not to run. Fewer moving parts means fewer updates, fewer failures and fewer repair hours.
Can I switch from one to the other later?
Yes, but it is a real migration project with a redirect map. Which is why the decision is worth making deliberately up front.