WordPress or a Custom-Coded Website? A Decision Guide for Small Businesses

Choose WordPress unless one of five things is true: people other than your editors change data on the site, it must apply business rules that are not publishing, it depends on a system WordPress plugins do not reach, nobody can maintain it, or you need strict control of every line. Then a custom build starts to earn its extra cost. Our WordPress development team works on both sides of this line, so we have no reason to push you either way.

Five questions, asked in this order

Answer these honestly, writing the answer down. Stop at the first question that gives a clear result.

1. Who changes the content, and how often?

If staff will add pages, posts, images or products every week without a developer, WordPress is hard to beat. Its editor and admin screens already exist and are documented by the project itself. WordPress now offers a Site Editor for headers, footers and templates, but only when you run a block theme, so check that your theme is one. A custom-coded site can offer the same comfort, but someone has to build every admin screen your editors will use, and that is a significant part of the effort.

2. Does the site only publish information, or does it make decisions?

Publishing means pages, articles, galleries, enquiry forms. Deciding means customer accounts with different views, quotes calculated from many inputs, approval chains, dashboards, bookings that check live availability. The more the site decides, the more you are bending WordPress. Plugins can add features: the official plugin guide describes a plugin as a bundle of PHP that extends core, and gives a full ticketing system with a client portal as one example. But a pile of plugins that must cooperate is its own risk. If decisions are the heart of the product, lean custom.

3. What must it connect to?

List every external system: payment provider, accounting tool, CRM, stock system, shipping rates, a partner's API. If a maintained plugin already connects the two, use it. If the connection is unusual, one-way, or must be exact (money, stock, medical or legal records), writing it as proper code with logging and tests is safer than trusting a general-purpose plugin.

4. Who will look after it, and what can they do?

A WordPress site can be maintained by many agencies and freelancers. A custom site can only be maintained by someone who is comfortable with that codebase. If your only technical contact is yourself, favour the platform with the bigger pool of people who can pick it up.

5. How long must it live, and who must be able to take it over?

Treat this as the tie-breaker. WordPress is open source software licensed under the GPL, so you are not tied to the supplier who built your site. With custom code you get the same freedom only if the contract says so: your own repository, written setup notes, and a second developer who has been able to run it.

Your situation and our recommendation

"Custom-coded" can mean three different things

Buyers often compare WordPress with "custom" without noticing that custom has several meanings, and the cost and risk differ a lot.

1. A custom theme or plugin on WordPress. You still have WordPress and its admin, with code written for your needs. A child theme is the usual method for changing an existing theme, because WordPress's developer handbook notes that the parent can be updated without erasing your changes.
2. Headless WordPress. WordPress stores the content, and a separate front-end application shows it to visitors. The two communicate through WordPress's REST API, which the handbook describes as exchanging data as JSON and powering interfaces and applications outside the theme.
3. A framework build. The site is a web application written on a framework, with its own database and admin. Laravel, for example, describes itself in its documentation as a backend framework with routing, validation, caching, queues and file storage built in, and it can pair with React, Svelte or Vue for the front end. Our Laravel and React development page covers this route.

When someone quotes "a custom website", ask which of the three they mean. The first usually involves far less new code than the third, and the third has no admin screens until someone writes them.

Headless WordPress: when it backfires

Headless setups suit teams that already have front-end developers, need the same content in a website and a mobile app, or have a design that a theme cannot deliver. They backfire for small businesses in these cases:

• You have one developer or none. You now run two systems, WordPress and the front end, each with its own hosting, updates and security.
• Your editors need to see what they are publishing. Previews, scheduled posts and layout editing usually have to be rebuilt in the front end.
• Features come from plugins. Forms, search, galleries and similar features that a theme draws on the page for you usually have to be rebuilt or replaced.
• Your reason is "it will be faster". Speed problems on WordPress are often caused by hosting, images or too many plugins, which can be fixed without changing the architecture. WordPress's handbook itself says you should not feel pressured to use the REST API if your site already works the way you need.

Our position: for most small business sites, headless is a solution looking for a problem. Revisit it when a second channel, such as an app, needs the same content.

Who can take the site over in five years?

Whichever route you choose, put the answer in the contract rather than the conversation. Ask for the following:

• Source code in a repository you own or can access.
• Written notes covering how to run it locally, deploy it and restore a backup.
• A list of every third-party service and paid licence, in your name.
• Hosting that meets the platform's stated needs. WordPress's own requirements page asks for a current PHP release, MariaDB or MySQL and HTTPS, and warns that old, unsupported versions can leave a site open to security risks.
• A named second person who has run the project.

A custom build adds a maintenance duty the brochure site does not have: someone must update the framework and its packages over time, or it ages in the same way an unmaintained plugin does.

Where this advice is wrong

Staying with WordPress is wrong if your logic is the product and the plugins you would need are small, abandoned or in conflict. Going custom is wrong if the main reason is that WordPress "looks cheap" or "is not secure": a well-kept WordPress site and a neglected custom site are not comparable. Splitting the job is often right: use WordPress for what it is good at, and write code for the part that makes decisions.

Next step

If you are unsure which of the three routes you need, send us a short description of the pages, the people who edit them and the systems they must connect to through the contact page. We will respond with a written quote and say plainly if a simpler option would do.