Ask a WordPress agency and the answer is WordPress. Ask a development shop and the answer is custom. Both will give you technical reasons that sound objective and are in fact a description of what they sell.
We build both, at published prices, so this is the version without a thumb on the scale.
The question that actually decides it
Not budget. Not scale. Not "how much traffic do you expect".
Who changes the site after launch, and how often?
That one question resolves most projects, and almost everything else is downstream of it.
If a marketing person needs to publish a landing page on a Tuesday without booking developer time, you want WordPress, and the discussion is over. If the site changes four times a year and every change is a design decision anyway, the case for a CMS is much weaker than it looks.
Where WordPress genuinely wins
Publishing velocity. Someone non-technical adding a page, a post, a product, a team member — without a deployment. This is the whole point, and nothing else does it as cheaply.
The ecosystem. Booking, memberships, multilingual, e-commerce — there is a mature plugin for almost anything, which means it exists on day one instead of being quoted as custom development.
Handover. If you part ways with your agency, the next one will know WordPress. A bespoke stack narrows the pool of people who can pick it up, and that is a real business risk that rarely appears in the proposal.
Cost at the small end. A brochure site on a well-built theme is cheaper on WordPress than hand-coded, and no amount of engineering pride changes that.
Where custom genuinely wins
When the interface is the product. Anything with genuine interaction — a configurator, a 3D scene, a calculator, an app-like flow. Building those inside a page-oriented CMS means fighting it continuously.
When performance is a business requirement rather than an aspiration. A WordPress site can be fast; it takes discipline, because the default trajectory is plugin accumulation. A custom build starts with nothing and you add what you need. Both can pass Core Web Vitals; only one of them does it by default.
When the data model is not pages. If your business logic is bookings with dependencies, or multi-role permissions, or anything you would describe as "a system", you are building an application. WordPress can be bent into that shape and the bending is the expensive part.
When the design cannot be a theme. Not "we want it to look premium" — every brief says that. We mean the layout itself is the differentiator and no template gets you there.
Three arguments to ignore
"WordPress is insecure." Neglected WordPress is insecure. So is neglected anything. The real difference is that WordPress is a large target, so neglect is punished faster. If nobody is going to apply updates, that is an argument about your maintenance arrangements, not about the platform.
"Custom is always faster." A careless custom build with four fonts and an unoptimised hero video will lose to a disciplined WordPress site. The platform sets the default, not the ceiling.
"You will own the code with custom." You own it either way, if your contract says so. Get ownership of the design files, the code, the domain and the hosting account in writing regardless of stack — that is a contract question, not a technology one.
The honest cost picture
At the small end, WordPress is cheaper and it is not close. At the top end the two converge, because a heavily customised WordPress build with bespoke blocks and custom data structures is doing the same work as a custom build while carrying a CMS along with it.
The crossover is roughly where you stop describing pages and start describing behaviour. Our published engagement levels cover both, and the reason the same brief can produce two different numbers is that the two stacks do genuinely different amounts of work for the same outcome.
What should worry you in a quote is not the number but the absence of one — a single figure with a paragraph under it, and no itemised scope. We wrote about why hourly rates are the wrong unit for this, and it applies to both stacks equally.
The decision, compressed
Choose WordPress if someone non-technical will change the site regularly; you need a mature plugin for a solved problem; you want the widest possible pool of future developers; the site is mostly pages.
Choose custom if the interface is the product; performance is a stated requirement with numbers attached; the data model is not pages; or the design cannot come from a template.
Choose either, carefully, if you are somewhere in between — and in that case pick on who maintains it, because that decides how the site ages.
If you want the version of this argument applied to your actual brief rather than in general, send it over. We will tell you which one we would build and why — including when the answer is the cheaper one.