Start with the decision, not the technology
The question “WordPress, headless, or custom?” sounds technical, but the right answer is primarily operational. Who writes the content? Which processes need to be automated? What data is sensitive? Which systems must connect? Who maintains the product after launch? Without those answers, any recommendation is simply a preference in attractive packaging.
There is no hierarchy in which custom development is automatically superior, headless is automatically modern, and traditional WordPress is automatically cheap. A well-built WordPress theme can be the healthiest choice for an editorial website. A headless architecture can usefully separate content from several interfaces. A custom application is justified when the product has its own business logic, roles, workflows, and data that do not fit a CMS.
What the three options actually mean
These terms are often used loosely. Before comparing them, it helps to establish what the company is actually buying in each case.
Traditional WordPress
WordPress manages the content and generates the public interface through a theme. The theme may be custom-built, use native blocks, or, when the project calls for it, use a controlled visual builder. Publishing, previewing, and displaying content all remain in the same system.
- Suitable for company websites, publications, campaign pages, and WooCommerce stores whose processes are close to standard.
- Editors work in a familiar workflow and can see the finished page more easily.
- There is one primary system to host, update, and monitor.
- It requires discipline around extensions, security, caching, and theme quality; a large plugin count is not a technical strategy.
Headless WordPress
WordPress remains the editorial interface, while the public website is a separate application—for example, one built with Next.js—that reads content through an API. This separation can provide greater interface freedom and distribute the same content to a website, mobile app, or other channels. In return, it creates two systems, two production publishing paths, and a synchronisation layer that must be designed deliberately.
- Suitable when the same content serves several products or when the public interface has requirements that an ordinary theme cannot meet.
- Preview, forms, search, authentication, and cache invalidation must be solved explicitly.
- Installing a WordPress plugin no longer produces a feature in the frontend automatically; the integration has to be built.
- The team must be able to operate both the CMS and the presentation application.
Custom application
A custom solution models the product’s users, permissions, data, and rules directly. It may include its own administration panel or a separate CMS for editorial areas. It is justified when the product’s difference lies in its behaviour: approvals, calculations, scheduling, collaboration, documents, automation, reports, or internal processes.
- Suitable for portals, SaaS platforms, CRM or ERP systems, marketplaces, and specific operational workflows.
- It provides control over the data model and experience, but every important capability must be designed, tested, and maintained.
- It should not be used to rebuild mature CMS editorial features on a custom-development budget.
Seven questions that clarify the choice
An architecture discussion becomes useful when every option is tested against the same criteria. The following questions expose costs and constraints before they turn into implementation problems.
1. Who publishes, and how often?
A website with dozens of authors, revisions, editorial scheduling, and preview has different needs from one updated quarterly by a single person. Ask to see the complete workflow: creation, review, approval, scheduling, preview, and correction. Do not assess a CMS from a screenshot of its editing screen alone.
- Can editors build pages without breaking the visual system?
- Are roles and approvals suited to the team?
- Does the preview show exactly what will be published?
- Does content need to be reused in apps, emails, or physical displays?
2. Does the website publish or process?
If the main outcome is reading a page and submitting a form, a CMS can remain at the centre of the project. If users create accounts, manage records, track states, collaborate, or complete a multi-step workflow, the product is becoming an application. At that point, the question is no longer “which theme should we use?” but “how should we model the data and rules?”
3. Where is the true source of data?
Establish which system is authoritative for products, prices, customers, stock, bookings, and documents. If WordPress merely displays ERP data, do not turn it into a second source of truth. If articles and pages are the central content, WordPress can naturally remain their source. Duplication without clear rules creates discrepancies that are hard to trace and requires manual correction.
4. How deep are the integrations?
Sending a form to a CRM is not the same as bidirectional synchronisation of stock, invoices, and customers. For each integration, record the data direction, frequency, volumes, authentication, API limits, failure behaviour, and who repairs a failed synchronisation. Choose the architecture around the most critical integration, not the easiest demonstration.
5. What are the performance requirements?
All three options can be fast or slow. Implementation, content, images, caching, infrastructure, and third-party scripts make the difference. Headless does not automatically repair unoptimised media, and WordPress does not automatically condemn a website to poor scores. Define important pages, served markets, update frequency, and measurable thresholds before using performance as an architecture argument.
6. Who will operate the system?
Architecture continues after launch. Who applies updates? Who responds to alerts? Who can change the headless frontend? How quickly can an urgent fix be published? A system that looks elegant in a diagram but cannot be operated by the available team is a poor choice. Include in-house skills and the maintenance relationship in the decision.
7. What is the lifetime cost?
Compare total cost, not only the initial proposal. Include analysis, design, implementation, licences, hosting, monitoring, updates, future development, security work, and the cost of changing suppliers. In a headless architecture, count the CMS and frontend separately. In a custom solution, include administration features. In WordPress, include extension maintenance and compatibility work.
Scenarios in which the choice becomes clear
- A marketing-managed company website with pages, case studies, and articles: traditional WordPress with a controlled theme and blocks is often sufficient and efficient.
- A publication that delivers the same content to a website, mobile app, and other products: headless can separate content from channels effectively if preview and caching are designed from the start.
- A customer portal with accounts, contracts, documents, approvals, and internal-system integration: the core should be treated as a custom application; a CMS may exist separately for public pages.
- A store with a relatively standard catalogue and checkout: WooCommerce can be pragmatic. Complex configurators, contract pricing, or unusual operations may require custom extensions or a dedicated backend.
- A short-lived campaign website with limited content: a static solution or simple CMS may be healthier than introducing a two-application architecture.
The costs most comparisons leave out
The most expensive feature is sometimes the one everyone assumed, not the one written into the proposal. In a headless architecture, a team may discover late that editorial preview or redirects do not arrive automatically. In a custom solution, a seemingly simple administration panel may need permissions, history, and validation. In WordPress, a quickly installed extension can become a critical dependency with no clear owner.
- Migration of content, metadata, and redirects from the old system.
- Preview, search, forms, transactional email, and file management.
- Roles, audit log, backup, restoration, and incident response.
- Test environment, production deployment automation, monitoring, and alerts.
- Documentation, editor training, and handover to another team.
- Accessibility, consent, data retention, and deletion on request.
How to decide without making a technology bet
For an important project, begin with a short analysis phase. Its result should not be a vague presentation, but a map of content, users, workflows, integrations, and risks. Compare two or three options against the same criteria and record why one was chosen.
- Describe the business outcomes and the actions users must be able to complete.
- Inventory the content types, sensitive data, and external systems.
- Separate launch requirements from assumptions about the future.
- Create an architecture outline and, where necessary, validate the riskiest integrations with a technical prototype.
- Estimate implementation and operation, including ownership of code, accounts, and documentation.
- Define exit criteria: performance, security, editorial experience, testing, and a recovery plan.
The best decision is not the one that sounds most advanced in a proposal. It is the one you can explain simply: which problem it solves, which complexity it accepts, and which options it keeps open.