WordPress, Headless or Custom: Choosing a Web Stack That Fits
Every web project starts with the same argument. Someone wants WordPress because it is familiar. Someone wants headless because it is modern. Someone wants a custom build because the requirements are unusual. All three can be right, and the decision is rarely about technology.
It is about who will maintain the site in three years, how often content changes, and what happens when the person who built it is unavailable.
Start With Who Edits the Content
This question settles more architecture debates than any benchmark. If a marketing person needs to publish a page on a Friday afternoon without involving a developer, that requirement eliminates certain options immediately.
WordPress is unmatched here. Its editing experience is familiar to millions of people, and someone who has used it once can use it again anywhere. A headless setup with a modern CMS can be equally good, but only if someone builds the editing interface properly — and that work is frequently underestimated.
A custom build with no CMS means every content change is a developer task. For a five-page brochure site that rarely changes, that is perfectly reasonable. For a site publishing weekly, it is a bottleneck that will be resented within two months.
What Each Option Actually Costs
Build cost is the number everyone compares. It is also the least important one, because it is paid once while maintenance is paid forever.
| WordPress | Headless CMS | Custom build | |
|---|---|---|---|
| Initial build | Lowest | Higher | Highest |
| Ongoing maintenance | Regular updates, moderate | Two systems to maintain | Entirely yours |
| Finding a replacement developer | Very easy | Harder | Hardest |
| Content editing | Excellent out of the box | Good if built well | Only what you build |
| Performance ceiling | Good with care | Excellent | Excellent |
| Security surface | Large — popular target | Smaller front end | Smallest, but unaudited |
| Time to launch | Weeks | Months | Months |
The row that decides most real projects is finding a replacement developer. A business that cannot easily hire someone to maintain its own website has taken on a risk that rarely appears in the original quote.
When WordPress Is the Right Answer
Which is more often than its reputation among developers suggests. WordPress makes sense when:
- Content changes regularly and non-technical people make those changes
- The site is primarily pages, posts and forms rather than a complex application
- Multilingual content is needed — the plugin ecosystem here is genuinely strong
- You want to be able to hire a maintainer from a large pool
- Time to launch matters
The criticisms of WordPress are usually criticisms of badly maintained WordPress. A site running fifty plugins, three of them abandoned, with a page builder generating megabytes of markup, will be slow and fragile. A site running eight carefully chosen plugins on a well-built theme is fast, secure and entirely pleasant to work with.
The discipline required is not technical. It is saying no to plugins.
When Headless Earns Its Complexity
A headless architecture separates content storage from presentation. The CMS provides an API; a separate front end consumes it. This is genuinely better when:
- The same content feeds multiple destinations — website, mobile app, in-product help
- Traffic is high enough that front-end performance materially affects revenue
- You have front-end developers who will still be there in two years
- The front end is genuinely application-like rather than document-like
The hidden cost is that you now maintain two systems and the contract between them. When the CMS changes a field name, the front end breaks. When the front end needs a new content type, someone must model it. Teams that adopt headless for a brochure site typically regret it within a year.
When a Custom Build Is Justified
Rarely for a website. Often for an application that happens to have a website attached.
If the core of the product is logic — calculations, workflows, integrations, user accounts with complex permissions — then a CMS is the wrong tool and forcing it will hurt. Build the application properly and give it a small content layer, rather than building an application inside a CMS.
The three products we run ourselves sit in this category. PostRSS is a scheduling and distribution engine; Talkmio is a real-time messaging system; Ask Mio is an assistant with tool integrations. None of them would work as a CMS site. All of them have marketing sites that do.
The Questions That Actually Decide It
Before choosing, answer these honestly:
- How often does content change, and who changes it? Weekly by a marketer points to a CMS. Twice a year by a developer does not.
- How long must this last? A campaign site for six months and a platform for ten years deserve different answers.
- Who maintains it if the builder disappears? If the answer is “we would need to find someone”, weight that heavily.
- Is the hard part content or logic? Content problems suit a CMS. Logic problems do not.
- What is the real performance requirement? Not “fast” — a number, tied to a business outcome.
Most projects that answer these carefully end up on WordPress or a straightforward custom build. Headless usually wins when there genuinely are multiple front ends.
The Mistake That Costs Most
Choosing for the team you wish you had. A stack that requires a full-time front-end specialist is a fine choice if you employ one. It is a trap if you are relying on an agency you may stop working with.
The second-most-expensive mistake is building for imagined future scale. Sites built to handle traffic that never arrives carry the complexity cost every day and receive the benefit never. Build for the traffic you have plus a comfortable margin, and rearchitect when the problem is real.
Frequently Asked Questions
Is WordPress secure enough for a business site?
Yes, when maintained. Almost every WordPress compromise traces to an outdated plugin, a weak password or an unpatched core. Automatic updates, a small plugin count and enforced strong authentication close nearly all of it.
Can WordPress be fast?
Very. A well-built WordPress site with proper caching and a lean theme outperforms a badly built React application comfortably. Slowness comes from page builders, plugin bloat and unoptimised images, not from WordPress itself.
Should I move an existing WordPress site to headless?
Only with a specific problem that headless solves. “Modernisation” is not a problem. If the site is slow, fix the causes first — they are usually cheaper to address than a rebuild.
What about site builders like Wix or Squarespace?
Fine for a small brochure site with no unusual requirements. The constraints appear later: limited control over technical SEO, difficulty integrating other systems, and no straightforward migration path when you outgrow them.
How many plugins is too many?
There is no number, but every plugin is code you did not write running on every page load. We aim for under fifteen on a business site and audit them yearly. Anything unused or unmaintained gets removed.
What does maintenance actually involve?
Core and plugin updates on a schedule, tested backups, uptime monitoring, security patching and a periodic performance review. It is unglamorous and it is the difference between a site that lasts five years and one that is rebuilt every two.
The Bottom Line
The best stack is the one your team can maintain without heroics. For most businesses publishing content regularly, that is a carefully built WordPress site with a small plugin count and someone responsible for keeping it current. For products whose difficulty is logic rather than content, it is a custom build. Headless sits between them and earns its complexity only when there really are multiple front ends.
Decide based on who maintains it, not on what is fashionable.
Our website development team works across all three, and our IT maintenance service exists because the second half of this decision matters more than the first. For further reading, the WordPress optimisation documentation is a good starting point.