WordPress or a custom website: which one to choose.

The short answer

Most small business sites could be built either way. The deciding questions are about the years after launch, not the launch itself:

• Who edits the site, and how often? Several people publishing every week points to WordPress. A few changes a year points either way.
• Does a feature you need already exist as a well-kept plugin, such as a store, an online course or a membership? Then WordPress saves you paying for it to be built.
• Does the site need something of your own, such as a quote calculator with your pricing rules or a booking flow that writes into your booking software? Then custom code bends less.
• Who looks after it? WordPress needs regular updates. A site built as plain pages needs far fewer.
• Who could take it over? Nearly every web developer knows WordPress. A custom site is easy to hand over only if it was built in a common way and you hold the code.

If most of your answers point one way, go that way. If they are split, read the section on mixing the two.

What custom means

People use the word for three different things, and quotes are hard to compare until you know which one you are being offered:

• A design of your own on WordPress. The site still runs on WordPress with its editor and plugins, but the theme was made for you instead of bought.
• A site built in code with no content management system. The pages are written by a developer and published as files, and changes go through the developer or a simple editor added for the parts you change.
• A front end built in code with a content management system behind it. Your team edits text in the system, and the site reads it from there. Some setups use WordPress itself as that back end.

This guide is about the platform under the site, not the look of it. Whether to buy a theme or have a design made for you is a separate choice, covered in what decides the price of a website.

When WordPress is the better choice

WordPress wins in more situations than studios that only build in code like to admit.

• Many editors. WordPress has roles built in: an editor publishes and manages everyone's posts, an author only their own, and a contributor writes but cannot publish. A clinic manager can approve what three practitioners draft.
• Frequent publishing. A firm that adds articles, case studies or news every week gets an editor built for it, with drafts, scheduled posts and saved revisions.
• A plugin already does the job. Stores, courses, memberships, event listings and translations all have established plugins. Paying for one of these to be built from scratch rarely makes sense for a small business.
• You want to stay independent. Because WordPress is so widely used, a local developer, an agency or a freelancer can take it over, and your content can move to any host.
• Your team already knows it. Retraining people on a new editor has a cost too.

If you choose it, choose it properly: a host that runs backups, as few plugins as the job needs, and one named person who runs updates and checks the site afterwards.

When a custom site is the better choice

Custom code pays off when the site is small and stable, when speed matters or when the site has to do something nobody has made a plugin for.

• A site that rarely changes. A two-van plumbing firm with eight pages that change twice a year does not need a full editing system, and every part it does not have is a part that cannot break.
• Speed on a phone. A page built for one job carries no theme options or plugin scripts it does not use. That matters for landing pages for ads, where you have paid for every visitor's click.
• A flow of your own. A quote form that prices a cleaning job from the number of bedrooms and extras, or a booking request that checks your rules before it reaches your booking software, is often simpler to build than to force out of several plugins.
• Fewer moving parts. Pages published as plain files need no database and far fewer updates than a site running a dozen plugins, though the code a site depends on still needs updating now and then.
• Software rather than a brochure. A customer portal, a booking dashboard or anything behind a login is closer to an application, and it is usually built in code whatever the public pages run on.

The cost of all this is editing. If your team wants to change pages often and freely, a custom site needs a proper editor added, or every change goes through a developer.

Editing after launch

This is the question that decides it for most businesses, so test it before you sign rather than after launch.

On WordPress, anyone with a login can edit any page they are allowed to. The risk is the opposite of a custom site's: a page builder plugin lets people move things around until the phone layout breaks, and nobody notices until a customer does. Roles help, and so does limiting which blocks your team can use.

On a custom site, there are two common setups. Either the parts you change often, such as prices, opening hours, team members and news, are editable in a simple system and the rest stays fixed, or you send changes to your developer. The second is fine when changes are rare and the developer answers quickly. It is a bottleneck when your prices change every month.

Ask whoever quotes to show you the editor you would get. Then try two jobs yourself: change your opening hours, and add a new team member with a photo. If either needs a developer, you know where your changes will go.

Upkeep and security

WordPress installs its own minor and security releases automatically on most sites. Plugins and themes update themselves only if you switch that on, and each one comes from a different developer on a different schedule. Updates now and then clash, so someone should check the site after each round and keep backups that run on their own.

Before you add a plugin, look at its page in the WordPress plugin directory: when it was last updated, which WordPress version it was tested with and whether its developer answers questions in its support forum. Skip any plugin that looks abandoned, however useful it seems.

A custom site has less to update, but not nothing. Its hosting, its security certificate and the libraries it was built with need attention, and a form or connection can stop when another company changes something. Ask who checks that, and how you hear about a failure.

Either way, write down who does the upkeep, how often and what it costs before launch. Website maintenance, line by line lists what that work covers. A site nobody looks after decays the same way on any platform.

Who can take it over

Sooner or later someone else may look after your site: a new studio, a freelancer or a person you hire. Plan for that on day one.

WordPress is the easy case. Many developers know it, the content exports in a standard format and the whole site moves to any host that runs WordPress. Keep the administrator login and the hosting account in the business's name.

A custom site is only as portable as the way it was built. Ask for these before you sign:

• The code in a repository the business owns, such as a GitHub account in your name, with the developer added as a user.
• A short written note on how the site is built, published and backed up.
• A common, well-known framework or plain files, rather than a system only the original developer understands.
• The domain, hosting and every account in your name, or handed over at launch.

If a developer will not put the code in your name, you do not own your website in any practical sense, whatever the contract says. Ask before work starts, while it is an easy question.

If a past developer already holds your domain, hosting or code, get your website back from a web designer covers the order to recover them.

How the costs differ

The two spread their costs differently, so compare them over a few years rather than at launch.

WordPress usually costs less where a theme or a plugin already does the job, and more over time: hosting, yearly plugin and theme licences, and someone's time for updates and the occasional fix after one.

A custom site costs more where something has to be built that a plugin would have provided, and less in yearly licences. Changes may cost developer time, so ask how they are charged.

Put both quotes next to each other with three columns: the build, what each year costs after it, and how a typical change is handled. Our own starting prices are on the prices page.

Connections to your other tools

Many small business sites need to talk to other software: a booking tool, customer records, an email list or accounting software. Either platform can do it, and either one is limited by what the other tool's API allows. The API is how a piece of software lets other tools read from it and write to it.

On WordPress, there may be a plugin for your booking tool or CRM already. Check who makes it, when it was last updated and what it actually syncs, because a plugin that copies contacts one way is not the same as one that keeps bookings in step both ways. Where no good plugin exists, a developer writes the connection as custom code inside WordPress, or links the two tools through a platform such as Zapier, Make or n8n, compared in Zapier, Make or n8n.

On a custom site, the connection is written for your tools from the start. That suits a flow of your own, such as an enquiry that lands in your CRM, alerts the right person and starts a follow-up. Automation covers how those connections are planned and tested, and what happens when one fails.

Six sites, and which way each should go

• A dental practice where the practice manager updates fees and news and three dentists write patient guides: WordPress, with roles so the manager approves each guide.
• A two-van plumbing firm with eight pages and ads running to two of them: custom, or a simple builder. Speed and a clear call button matter more than editing.
• A law firm whose partners publish an article every week: WordPress. Its editor and scheduled posts fit the way the firm works.
• A shop with two hundred products: a store platform such as Shopify or WooCommerce, which is a WordPress plugin. Building a store from scratch is rarely worth it at this size.
• A cleaning company whose quote form prices a job from bedrooms and extras and sends it to its customer records: a custom form, either inside WordPress or as part of a custom site.
• A tutoring centre that wants parents to log in and see lessons and invoices: a custom web application for the portal, whatever the public pages run on.

You do not always have to choose one

The two mix well, and a mix is often the honest answer:

• WordPress for the pages your team edits, with one custom-built page for the job WordPress does badly, such as a quote calculator.
• A custom site for speed, with a simple editor behind it for prices, opening hours and news.
• A custom front end that reads its content from WordPress, so editors keep the WordPress screens they know.

Each mix adds a little complexity, so choose one only when it solves a problem you actually have. A business with ten stable pages and no special features does not need any of this. A builder may suit it best, as Wix, Squarespace or WordPress explains.

Questions to settle before you decide

Whoever builds it, get written answers to these:

• Which platform do you recommend for us, and why that one rather than the other?
• Who will edit which pages, and can you show me the editor?
• Which plugins or libraries will it use, and who renews any licences?
• Who runs updates, how often, and who checks the site afterwards?
• Where is the code kept, and is it in our name?
• What happens to the site if we stop working with you?

We build on WordPress, Shopify or in code, depending on who edits the site and what it has to do, and we say which and why after the free consultation. See websites for how a build runs.