WordPress, custom software or a headless CMS? Choosing the right foundation

You have three proposals on the desk. One agency says "WordPress, live in eight weeks". Another wants to build something bespoke, "exactly the way you work". The third talks about Next.js, a headless CMS and pages that load before you have finished clicking. All three sound certain, and all three can explain in one sentence why the other two are wrong. Soon you are judging salespeople rather than platforms.

This article compares the three routes from the side of the organisation that lives with the site for five years, not the vendor who builds it. We cover your content team's daily work, security, speed, languages, integrations, hosting, the cost lines nobody quotes and what leaving would take, then finish with a decision table and first steps.

What do the three options actually mean?

WordPress combines the editing interface and the pages your visitors see in a single application. It runs on PHP and MySQL (or MariaDB), pages are rendered on the server through a theme, and anything the core does not do is added with a plugin. We mean the open-source WordPress on your own hosting, not the hosted WordPress.com service.

A headless CMS splits those two halves. Content is entered in an editing interface and delivered through an API; the website itself is a separate front-end application, usually written with a framework such as Astro or Next.js. Headless systems fall roughly into two camps: commercial cloud services such as Contentful, and open-source systems such as Strapi or Payload that you can run on your own servers. Sanity sits in between. Its editing interface, Sanity Studio, is open source, while the content lives in Sanity's hosted data store.

With custom software, the data model, admin interface, permissions and business rules are written for you. The work usually sits on a framework such as Laravel, Django or a Node.js stack. The trade-off is easy to state: custom software has none of the limits of an off-the-shelf system, and none of its ready-made features either.

There are hybrids too: WordPress as a pure editing back end feeding a separate front end through its REST API or the WPGraphQL plugin, or a headless CMS for marketing pages next to a custom-built customer portal. Often the real question is "which one for which part?".

How does your content team's day change?

You are probably not the one using the site every day; your marketing manager or a new junior is, and the decision is felt most on their screen.

The WordPress block editor is familiar territory. What you type looks close to the finished page, preview is one click away, and roles such as Administrator, Editor, Author and Contributor come built in. Problems usually come from too much freedom: once page builders let every editor design layouts, a year later you have thirty pages that look like five different companies.

In a headless CMS, content goes into predefined fields: headline, summary, image, product code, related services. The design is locked in the front end, so editors cannot break it. That consistency is a real gain with a cost attached, because seeing the page while you write needs extra work. Next.js Draft Mode or Sanity's visual editing tools solve it, if someone plans for them at the start rather than after launch.

In custom software, the admin interface is exactly what was specified and nothing more. It can fit your workflow better than WordPress ever will, but every new field or page type becomes a development ticket. For a team publishing twice a week, that friction gets old quickly.

Picture a mid-sized engineering firm with a bilingual product catalogue and a few news items a month. Product pages are structured data (dimensions, certificates, compatible parts), while news is free text. The firm needs a field-by-field model and a comfortable editor at the same time. All three options can deliver that; the difference is how much effort it takes, and whose.

Plugins and security: where does the risk build up?

WordPress core is in good shape these days; the risk gathers around it. Patchstack, a company that specialises in WordPress security, reported in its annual review published in early 2026 that 91 per cent of the new vulnerabilities disclosed in 2025 were in plugins and 9 per cent in themes. Only six were reported in core, all low priority. The problem is not WordPress itself but the fact that every component you add brings its own author, maintenance rhythm and risk.

A site with forty plugins is not automatically dangerous. The dangerous ones are the form plugin nobody has updated for two years, the premium theme downloaded from a pirate site and the backup tool installed "temporarily" and then forgotten. Since WordPress 5.5, plugins can update themselves automatically. That speeds up security fixes and also means an update can break the site overnight, which is why tested backups and a named person watching updates are not optional.

In a headless architecture, the editing interface is separate from the public site. If the site is generated as static files, there is not even a database for an attacker to talk to. That shrinks the attack surface considerably without removing it: API keys, webhook endpoints, permissions on your cloud accounts and supply-chain risk from npm packages become your new homework.

Custom software gets no community patches. Someone has to follow the framework's security releases, scan dependencies with tools such as Dependabot or Renovate and commission a penetration test before launch. Left alone, custom code can be more exposed than the oldest WordPress install on the internet.

Whichever route you take, four rules stay the same:

• Two-factor authentication on every admin account, and no more permissions than each person needs.
• Backups whose restore has actually been tested. A backup that exists is not a backup that works.
• One named person or team responsible for updates, written into the contract.
• Regular clean-ups of unused plugins, accounts and API keys.

Speed and languages: what does the platform decide?

Both are claimed loudly in pitches and rarely measured.

Speed: does it come from the platform or from the build?

Both, but mostly from the build. With a lightweight theme, page caching and a CDN, WordPress loads quickly. With a heavy page builder, a dozen tracking scripts and uncompressed images, even the newest framework crawls.

What Astro and Next.js change is the default. Astro renders pages to static HTML out of the box and ships JavaScript only for components that need interaction, an approach it calls "islands". Next.js lets you choose per page between static generation, server rendering at request time and regeneration at intervals. When pages are prepared in advance and served from a CDN, there is no database query left for the visitor to wait on.

The trap: a headless site that runs too much JavaScript in the browser can end up as sluggish as the clumsiest WordPress build. A technology label is not a measurement, so test the sites each bidder has already delivered. Our article on Core Web Vitals explains which numbers to look at.

Multilingual sites: which platform handles several languages well?

If you are planning a site in English, German and Arabic, say, this point alone can settle the decision.

WordPress core has no multilingual content management. The official roadmap lists it as phase four, "core implementation for multilingual sites", while the phase under way is collaborative editing. Until then you work with plugins such as WPML or Polylang. They do the job, but each language behaves like a separate record, and compatibility with your theme and other plugins gets retested with every update.

In most headless systems, localisation is part of the content model. Contentful defines locales per environment and lets you choose field by field what gets translated. Strapi 5 ships internationalisation in its core, and in Payload you mark translatable fields in the configuration. On the front end, Astro has built-in i18n routing and locale-based routing is an established pattern in Next.js. Your front-end team still builds the hreflang tags, language switcher and URL structure. Arabic adds right-to-left layout, which is design and front-end work on every platform.

In custom software, multilingual support belongs in the data model from day one. Adding languages later turns into a rewrite that touches almost every table, so if a second language is even a possibility, say so during discovery.

Integrations, hosting and maintenance

Integrations

Few business websites live alone. Forms go to a CRM such as HubSpot or Salesforce, product data comes from an ERP, newsletter sign-ups go to an email platform. WordPress has a plugin for almost everything; quality depends on the author, and two plugins fighting over the same data is not unusual. In headless and custom builds, integrations are written in code: more effort, but you know exactly what goes where and when. If prices and stock levels have to come out of SAP, Microsoft Dynamics or NetSuite, expect integration work on any platform.

Hosting

WordPress needs one server running PHP and MySQL, or a managed WordPress host. A headless set-up has at least two parts, the content system and the front end, plus a build pipeline and webhooks that rebuild the site when content changes. According to the Next.js documentation, an application can run on a Node.js server, in a Docker container, as a static export without server-dependent features, or through adapters for platforms such as Vercel. Astro's static output can be published on a plain web server.

Hosting also decides where personal data sits. With a cloud CMS, check which region stores your content and form data, and make sure a data processing agreement is in place under GDPR or UK GDPR. Self-hosted systems keep that data on infrastructure you choose.

Maintenance

On WordPress, maintenance means core, theme and plugin updates, PHP version upgrades and backups. On the headless side you have major framework releases, the Node.js release schedule and upgrades of the content system itself. Moving from Strapi 4 to Strapi 5, for example, brought breaking changes along with its own migration guide and code-transformation tooling. Custom software has all of that, plus the question of who still understands the system.

Total cost of ownership: the lines that never make it into the proposal

The build quote is the tip of the iceberg. Ask each bidder to list the following separately for a three-year view; even without figures, seeing which lines exist changes the picture.

• Build: design, front end, content model, migration of existing content.
• Licences: premium theme and plugin renewals, cloud CMS plan limits on users, records, locales or API usage, and enterprise features. In Strapi, single sign-on, review workflows and audit logs sit in paid plans.
• Hosting: servers, CDN, database, build minutes, front-end platform.
• Maintenance hours for updates, upgrades, security monitoring and backup checks.
• Your team's time. A slow, confusing admin steals minutes every day; nobody invoices for it, but you pay.
• Change requests: a new page type, a new field, a new integration.
• Training and documentation for the next editor who joins.
• Exit cost: the effort of moving to another system one day.

The mistake we see most often is treating the lowest build quote as the lowest cost. A rushed WordPress site resting on twenty plugins shows its real price in year two through maintenance hours and in year three through a rebuild. Our article on what drives website costs helps with reading quotes line by line.

Vendor lock-in and the cost of leaving

Lock-in is not one thing. It is at least four.

• Platform lock-in: with a cloud CMS, content lives on that company's infrastructure. You can export it through the API, but if prices or terms change, your bargaining position is weak.
• Code lock-in. If one agency wrote your custom software and kept the source code, documentation and server access, you own the system on paper and they own it in practice.
• Format lock-in: page builders store content in their own shortcodes or data formats. Remove the plugin and pages turn into fragments of meaningless markup.
• People lock-in, which is what happens when the only person who understands the system leaves.

Open-source licences reduce that risk without removing it. Two recent examples: the Payload team joined Figma in 2025, and the company behind Astro joined Cloudflare in January 2026. Both projects have said they will remain open source under the MIT licence, which is reassuring. Even so, a tool's roadmap is shaped by whoever employs its maintainers, and knowing who stands behind a tool is part of due diligence.

How hard a migration is depends on the direction. WordPress stores content as HTML marked up with block comments; moving it into a structured headless model means parsing and cleaning it field by field. Images, author data, SEO titles and redirects from old URLs are separate work items. Our relaunch checklist covers what a missing redirect plan can do to search visibility.

Decision table: which option fits which situation?

The table is not a law of nature; it sums up the choices that most often prove right in practice. Where several rows fit, the deciding factors are usually how your content team works and how much upkeep you can carry.

One row is missing on purpose: decisions made because "everyone uses Next.js now" or "WordPress is outdated". Neither is a reason; both are remarks about fashion. The useful question is who will update the content, how often and in how many languages, and who will keep the system running for five years.

Where to start

1. Draw up a content inventory: which page types exist, and who updates them, how often and in which languages?
2. List every system the site must connect to: CRM, ERP, email platform, payments, maps, booking.
3. Ask each bidder to fill in the cost lines above separately, and look at three years, not one.
4. Put the same questions to every bidder. Who runs updates? In whose name are accounts opened? If we leave, how do we get our content out?
5. Run a short trial with an editor: one news item and one product page in two systems, noting where they get stuck.
6. Check the company, licence and recent release history behind the platform you are leaning towards.
7. Write the decision and its reasons on one page, so the answer to "why did we do it this way?" is still on file in two years.

At AYTE Digital we build on all three routes, and we decide which one to recommend in a discovery session, based on your content workflow and how much maintenance you can realistically take on. If it helps, we can review your current site or the proposals on your desk and fill in the table for your situation.