WordPress vs Custom-built website

The phrase WordPress vs coding suggests a choice between a tool that needs no programming and one that does. It is a misleading split. A simple WordPress site can be assembled from a bought theme and plugins without writing code, but a professional one usually has a custom theme written in PHP, HTML, CSS and JavaScript, and often custom plugins for anything specific to the business. So the real difference lies in how much of the site comes ready-made and how much is written for you.

A custom-built website sits further along that line. The page structure, templates, routing and behaviour are written as an application, and there is no general-purpose platform underneath deciding how pages, menus or users work. Today that most often means Next.js, the React framework, which can generate pages ahead of time, render them on the server per request, or regenerate cached pages in the background when content changes. Content usually comes from a headless CMS, a content service that stores and edits content but has no opinion about how it is displayed. Sanity, Contentful, Strapi and Payload are common examples, some sold as hosted services and some open source and self-hosted. For sites with very little change, content can simply live in files in the codebase.

Between the two sits headless WordPress: WordPress kept as the editing system, with its content exposed through the REST API or a GraphQL plugin, and a Next.js front end rendering the pages. It gives editors the admin they know and visitors a modern front end, and it costs you two systems to run and the loss of plugins that expect WordPress to render the page.

There is also a lighter category worth naming, if only to set it aside. Hosted website builders such as Squarespace, Wix and Webflow are often the right answer for small sites where nobody wants to think about hosting or updates at all. They are outside the scope of this page, which assumes you have already decided the site warrants either a properly built WordPress site or a custom one.

More of these decisions should turn on editing than usually do. Before choosing, write down who will change the website after launch, how often, and what kinds of change they will make. Fixing a typo, publishing an article, building a new landing page and adding a new section type are four different jobs, and the two approaches handle them very differently.

WordPress’s editing experience is mature in ways that are easy to underestimate. The block editor, media library, revisions, scheduled publishing, user roles, drafts and previews all exist on day one and behave the way editors expect. A well-built theme adds custom blocks that match the design system, so editors can assemble new pages from approved components without a developer. That independence is the main reason WordPress wins content-led projects, and it costs nothing to build because the platform already has it.

On a custom build, the editing experience is something you design and pay for. A good headless CMS gives editors structured fields, workflows and roles, and some offer visual, click-to-edit previews. Next.js supports draft previews against CMS content, but connecting them properly takes work. The result can be excellent, sometimes better than WordPress for structured content, because editors fill in defined fields and cannot break the layout. It is also more constrained. If marketing wants a page layout nobody anticipated, that becomes a request to a developer to build a new component, rather than an afternoon in the editor.

So the honest test is the change log. Look at the changes made to your current site over the last year. If most were content and new pages built from existing patterns, WordPress serves you better. If most were new functionality, integrations and structural changes that needed a developer anyway, the editing advantage matters less and a custom build loses little.

WordPress’s plugin ecosystem is its greatest strength and the source of most of its problems. A plugin can add a feature in minutes, and each one is also third-party code running with full access to your site, maintained on its developer’s schedule, which may stop at any time. Sites accumulate them. A form plugin, an SEO plugin, a slider, a backup tool, a security plugin, a page builder and its add-ons, and by the third year nobody can say which plugins are still needed or what would break if one were removed. That accumulation is a form of technical debt, and it is the most common cause of slow, fragile and compromised WordPress sites.

Page builders deserve particular mention. Visual drag-and-drop builders give marketers real layout freedom, which is why they are popular. They also add weight to every page, tie the content to the builder, since some store layouts in formats only the builder can read, and make a later redesign or migration harder because the content and its presentation are tangled together. The native block editor, combined with custom blocks built for your design, gets most of the flexibility with much less weight and much less lock-in.

The security picture follows from that. WordPress core is mature and closely examined, and most compromised sites were running outdated or abandoned plugins, weak administrator passwords or neglected hosting. All of that is preventable with a short plugin list, prompt updates, strong authentication and monitoring, and all of it is routinely neglected by owners who believed the site was finished at launch.

Custom sites are not immune, and anyone saying otherwise is selling the rebuild. Next.js and React have both published serious security advisories that required prompt upgrades, and a custom site also depends on many open-source packages that need keeping current. What changes is the shape of the risk: a statically generated site with no admin login on the public server offers attackers very little, and the dependency list is something your developers chose and can audit. The work is less frequent and more technical, and it still has to be done. A custom site left untouched for two years can also become hard to update safely.

Custom sites are often sold on speed, and the claim is half true. A Next.js site that generates pages ahead of time, serves them from a content delivery network and sends only the JavaScript each page needs can be extremely fast, and it gives developers precise control over what loads and when. That control is real and worth having when performance is commercially central.

It is not automatic. A custom site that ships a large JavaScript bundle to every visitor, loads fonts and images carelessly or renders everything in the browser can be slower than a well-built WordPress site, and plenty are. The framework makes speed achievable and does not guarantee it.

WordPress, meanwhile, is not inherently slow. A lean theme, a short plugin list, full-page caching, a content delivery network and properly sized modern image formats make a WordPress site fast on modest hosting. Slow WordPress sites are nearly always slow for the same reasons: page builders, plugins that each add scripts and styles to every page, uncompressed images, and no caching. Those are problems of the build, and rebuilding on the same platform fixes them.

On either platform the biggest performance problem is often the third-party scripts the business adds later: analytics, chat widgets, tag managers, embedded video, consent banners and advertising pixels. They cost the same on both. Before choosing a platform for speed, measure your current site’s Core Web Vitals and find out where the time actually goes. If it goes on a bloated theme and plugins, a well-built WordPress site solves it. If it goes on scripts you are committed to keeping, a platform change will not help.

Build prices vary too much by scope and supplier for a figure here to mean anything, so compare the structure instead. Over three years, the question is how much each approach costs to build, to run, and to change, and the third line is the one most comparisons leave out.

WordPress usually costs less to build, because much of the platform already exists. Running costs are hosting, ranging from cheap shared plans to managed WordPress hosting that carries much of the operational work, plus premium plugin and theme licences, which are often annual, plus maintenance: updates, backups, monitoring and fixes, whether through a retainer or someone’s time. Changing content costs nothing beyond the editor’s time. The risk is the rebuild: sites that sprawl, accumulate plugins and build pages in a heavy page builder often need rebuilding within a few years, and that cost belongs in the comparison.

A custom build usually costs more to build, because the templates, components, content model, previews and integrations are all made for you. Running costs can be modest, since static and serverless hosting are often inexpensive at brochure-site traffic levels, plus a headless CMS subscription priced by seats, usage or tier, or the cost of self-hosting an open-source one. Framework and dependency upgrades are developer work, less frequent than WordPress updates and larger when they come. Every change that is not content, such as a new page type, a new section or a new form, is developer time.

That last point decides most three-year comparisons. If the site mostly changes through content, WordPress’s lower build cost and free editing usually win over three years. If the site changes through new functionality that needs a developer on either platform, the custom build’s higher starting cost is spread across work you were paying for anyway, and its cleaner codebase can make each change cheaper. Estimate how many non-content changes you expect each year and what each costs on each approach, and the comparison becomes concrete.

One structural risk applies to custom builds in particular: dependency on whoever wrote the code. A WordPress site can be handed to another agency easily. A custom codebase can too, if it is clean, typed, tested and documented, and if it is not, you are tied to its authors. Make handover quality a written requirement of any custom build.

Both approaches can leave you dependent on someone. The dependency simply sits in different places, and it is worth knowing where before you sign anything.

WordPress itself is about as portable as software gets. It is open source under the GPL, it runs on any PHP host, its content lives in a standard database, and moving a site between hosts or between agencies is routine work. The lock-in on WordPress comes from inside the site rather than from the platform: a commercial page builder that holds every layout, a theme framework with its own conventions, or plugins that keep important data in formats only they understand. A site built that way is portable in theory and expensive to move in practice, which is another reason to keep the plugin list short and the theme your own.

On a custom build, the code should be yours outright. That means your own repository, intellectual property assigned to you in the contract, and the build documented well enough that another team could deploy it. Check all three before the work starts. The less obvious dependencies are the services around the code. A hosted headless CMS keeps your content in the vendor’s service, so confirm you can export everything through its API, and read how its pricing grows with seats, usage or content volume, because a brochure site’s needs rarely stay still. Next.js is developed by Vercel, and some of its features are easiest to use on Vercel’s own platform. It also runs on any Node.js server, in containers, or as exported static files, but which features survive a move between hosts is worth checking at the start rather than discovering when you want to change.

Whichever you choose, keep the accounts that matter in your organisation’s name: the domain, the hosting, the CMS, the repository and the analytics. Supplier relationships end for ordinary reasons, and the cost of an ending depends almost entirely on whether you hold the keys when it happens.

Pulled together, the case for custom is strongest when several of these hold at once: the site has application features such as accounts, dashboards or tools; it publishes large numbers of pages from structured data; its content feeds other channels; performance is tied directly to revenue at meaningful traffic; the security posture favours a minimal surface; and there are developers committed to owning it for years. One of those alone is rarely enough. Three or four together usually are.

The case is weakest, and custom becomes overkill, when the site is a brochure of a few dozen pages, when the marketing team needs to build new layouts without developers, when the budget is tight, or when nobody will own the code after launch. It is also overkill when the real complaint is a badly built WordPress site, because a disciplined WordPress rebuild with good web design fixes that at a fraction of the cost, and keeps the editing experience your team already knows.

Headless WordPress deserves consideration whenever both sides have real requirements: editors who know WordPress and a front end that needs the control of Next.js. Be clear about the cost. It means two systems to host, update and secure, a build process connecting them, previews to wire up, and plugins that no longer work because they assumed they controlled the front end. It suits organisations with a significant content operation and genuine front-end ambitions, and it is a poor fit for a small site that wanted to be slightly faster.

A last test, which settles more of these decisions than any feature list: picture the site in its third year. Ask who is publishing on it, who is changing it, and who gets called when something breaks. If the answers are a marketing team, a small agency and a managed host, build it on WordPress. If the answers are your own developers, building new features into it alongside your product, a custom build will repay its cost.

Moving from WordPress to a custom site is mostly a content and URL project, and the code is the easier part. Posts, pages, media, categories and authors can be exported through the WordPress REST API or its export tools and imported into a headless CMS, but content rarely moves cleanly. Years of pages built in a page builder, shortcodes, embedded layouts and inconsistent formatting have to be cleaned, and often restructured into the new content model. This is the stage most migrations underestimate, and it is worth sampling the messiest pages early to see how much manual work they need.

Protecting search visibility means mapping every URL that has traffic or links to its new address, redirecting each old URL permanently, and carrying across titles, descriptions, structured data and canonical tags. Forms, analytics, consent tools and any integrations the plugins quietly handled need inventorying and rebuilding, because nobody remembers them until they stop working.

There is a lower-risk route worth considering: go headless first. Keep WordPress as the editing system, build the new Next.js front end against its API, and switch the front end over section by section. Editors keep working throughout, and if you later want a different CMS, the content can move separately from the front end. The cost is running both systems during the transition.

Moving the other way, from a custom site back to WordPress, happens more often than people admit, usually because the developers who built the custom site have gone and nobody can change it. The work is similar in reverse: model the content as WordPress post types and fields, rebuild the templates as a theme, migrate the content and redirect the URLs. Before doing it, check whether the actual problem is the platform or the loss of the people who knew it. Sometimes a capable developer taking over the existing codebase is cheaper than changing platform. Sometimes it is not, and WordPress’s large pool of maintainers is exactly the point.