WordPress or a
bespoke website?

The first quote, almost always: the core is free and there are ready-made themes and plugins that save hours of development, so on handover day it usually wins on price. The question that matters is about the next three years, not day one. If nobody updates the core, plugins and theme, WordPress piles up known vulnerabilities and ends up causing real grief: a site that's down, hacked or penalised in search engines. If someone maintains it, for a small monthly fee or an hour or two each quarter, it stays good value for years. A badly planned bespoke website also gets more expensive over time, for the opposite reason: if only the person who wrote it knows how to change it and they no longer answer, any change becomes a new project. The handover price isn't the cost of owning it; what decides the real cost is who looks after it afterwards.

Yes, with both, though in different ways. WordPress comes with an admin panel as standard that many people have already seen at some point, with a short learning curve for changing text, photos or prices without touching code. A bespoke website doesn't come with one out of the box: you have to ask for it and have it included in the development, usually as a custom panel simpler than WordPress's because it only manages what that business needs to change, not a line more. The real difference isn't whether it can be edited, but whether someone planned for it from the start. If a quote for a bespoke website doesn't mention any editing panel, ask before signing: it's one of those lines that, if it isn't written down, turns into an argument the day you want to change a phone number or a price and find out only the person who coded the site can do it.

The WordPress core, maintained and updated, isn't especially insecure: large and small sites use it without major problems. What is insecure is an abandoned WordPress: an old unpatched version, five plugins nobody has updated in years, a theme bought from a site that no longer exists and, sometimes, still the default admin password. That combination is the real way in, not the software itself. It's an important nuance because it changes the question to ask before choosing WordPress: not «is it secure?» but «who's going to keep it updated?». If the answer is nobody, the insecurity doesn't come from the CMS but from neglect, and something similar would happen to any software with that many moving parts. With real maintenance, up-to-date updates and a few well-chosen plugins, WordPress is a solid option for most service and retail websites.

When the business doesn't naturally fit «pages plus blog plus standard shop», which is what WordPress and its plugin ecosystem do well. If there's a process specific to the business (a booking with particular rules, a price calculation depending on unusual variables, an integration with an internal system that has no ready-made plugin), forcing it into WordPress with generic plugins usually ends in a fragile solution: it works, but nobody fully understands why, and every plugin update risks breaking something. That point is different for every business; no company size marks it on its own. The clearest sign is counting how many plugins it takes to simulate something they weren't built for: if the list keeps growing, the problem probably isn't configuration any more but the tool, and that's where a bespoke website starts to justify the extra effort up front.

It can, as long as that was planned when building it, as with any other website. The problem isn't the bespoke approach itself, it's handing over closed code with no management panel, so that any change, however small (a phone number, opening hours, a photo), means calling whoever coded it and paying for it. That isn't a feature of bespoke work, it's a badly delivered website, and it happens with in-house developments and badly assembled templates alike. A well-planned bespoke website includes a panel tailored to what that business needs to change often, even if it's smaller than WordPress's because it doesn't manage anything that won't be used. Before commissioning a bespoke build, ask explicitly who will be able to change what without depending on a third party, and ask to see it working before final handover, not just have it described to you.

It depends on who's going to maintain the website, not on which technology we prefer to use. If you'll be going in every week to change offers, product photos or blog posts, you need a clear, familiar panel, and there a well-built WordPress is usually the most sensible option: there's no point paying for bespoke development to reinvent something WordPress already does well. If it's a services site touched two or three times a year, you don't need a content management system designed for daily publishing; a simpler bespoke website, with code maintenance instead of plugin maintenance, usually works out cleaner in the long run. And if the business has its own process that doesn't fit standard pages and a shop, bespoke stops being a preference and becomes the only sensible option. The first thing we ask isn't the budget: it's who's going to go in and change it next year.

Yes, and it's a path taken fairly often when a business grows faster than expected. It has a real cost worth anticipating: the content has to be migrated, the URLs should be kept or properly redirected so you don't lose the rankings you already had, and the design is almost always redone because the two systems don't share templates. It isn't starting from scratch entirely, because the text, images and knowledge of the business already exist, but it isn't a frictionless change either. So it's worth avoiding building it twice if you can know from the outset: if you have good reason to think that within a year you'll need processes or integrations WordPress doesn't handle well, it's worth saying so in the first conversation, even if that means going bespoke straight away. Starting on WordPress out of caution, with a clear plan to review it in a year, is a reasonable strategy, not a mistake, as long as it's a conscious decision.

They can be bought together for convenience, but they shouldn't be mixed up with ownership of anything. A provider offering domain, hosting and development in one package isn't a problem in itself; the problem arises if, within that package, the domain is registered in the provider's name instead of yours. The domain is yours regardless of who builds the website, who hosts it or who maintains it: it's your business's name on the internet, not just another technical piece of the project. Before accepting an all-inclusive package, ask explicitly whose name the domain is registered in and check that you can access that account yourself, not just the website's panel. It's easily overlooked because it looks like an administrative detail, and yet it's the piece that, if handled badly, is the most expensive to put right later.