WordPress or custom code? The questions that actually decide it

Every project starts the same way: someone needs a website or an app, and the first real decision is what to build it on. Get it right and the thing is cheap to run and easy to change. Get it wrong and you pay for it every month for years.

We build both WordPress and fully custom applications, so we have no reason to push you one way. Here is the honest version of how we decide.

Start with what changes, and who changes it

The single most useful question is: who edits this, and how often?

If a non-technical person needs to publish a blog post, swap a hero image, or add a team member every week, WordPress (or a similar CMS) earns its keep. The editing tools already exist, they are battle-tested, and your team does not need us to change a headline.

If the "content" is really data — bookings, inventory, user accounts, dashboards — then a CMS is the wrong shape. You are not editing pages, you are running a system. That is custom-code territory.

The three questions that actually decide it

1. Is it pages, or is it a product?

A marketing site, a blog, a portfolio, a small shop — these are pages. WordPress does them well and cheaply. A booking platform, a member portal, an internal tool — these are products. They have logic, state, and rules that no page builder models cleanly.

2. How weird are the rules?

Every business has rules. "Gold members get free shipping over £40, except in the EU, except during a sale." WordPress plus plugins can bend to a point. Past that point, every new rule fights the last one, and you end up with six plugins arguing with each other. Custom code has no opinion about your rules — it just does what you write.

3. What happens at scale?

A hundred products and a thousand visitors a month? WordPress is fine. A hundred thousand products, real-time inventory, and traffic spikes? You will spend more taming WordPress than you would have spent building the right thing once.

Where WordPress quietly wins

It is easy to over-engineer. We have watched founders pay for a custom build when a well-configured WordPress site would have shipped in a third of the time for a fifth of the cost — and been easier for their team to run.

If your site is mostly content, your rules are normal, and your team wants to self-serve, WordPress is not a compromise. It is the correct answer.

Where custom code pays for itself

Custom code costs more up front. It pays that back when:

• the product is the business, not a brochure for it;
• you expect to keep adding features for years;
• performance is a feature, not a nice-to-have;
• you have integrations that no plugin covers.

The tell is usually the word "just." "Can we just add..." — if that sentence keeps ending in things a CMS was never built for, you have outgrown it.

The hybrid nobody mentions

Plenty of our builds are both. A fast marketing site in WordPress, and a custom app behind a login for the part that actually runs the business. Your team edits the pages they touch daily; the complex machinery lives where complexity belongs. You do not have to pick one tool for the whole company.

How to sanity-check a quote

If someone quotes you custom code for a five-page brochure site, ask why. If someone quotes you WordPress for a real-time logistics platform, ask harder. The right builder should be able to explain the trade-off in a sentence — and should be willing to talk you out of the more expensive option when it does not fit.

That is the whole trick. Match the tool to what changes, who changes it, and how strange the rules get. Everything else is detail.