Why we chose headless WordPress

For years we avoided recommending WordPress to our clients. The reasons were the usual ones: bloated themes, plugins of inconsistent quality, recurring security issues, and a development experience that felt stuck in 2012. But something changed in recent years, and it’s worth explaining what.

The problem with the alternatives

We tried virtually every modern option: Sanity, Contentful, Strapi, Payload, Storyblok. Each has real virtues, but also significant tradeoffs. Some are expensive on content-heavy projects. Others have editorial interfaces that marketing teams hate. Others require your team to learn entirely new paradigms.

What we needed

We needed a CMS that met three conditions simultaneously: editors could use it without training, the cost was predictable even at scale, and we had full control over the frontend.

The headless solution

By separating WordPress as a content backend and building the frontend with modern frameworks like Next.js or Astro, we got the best of both worlds. Editors continue working in an interface they already know. We build extremely fast sites without the limitations of traditional themes.

Concrete benefits

• Load times consistently under one second
• Ability to deploy the frontend on edge
• Total independence from the presentation stack
• License costs: zero
• Learning curve for editors: none

The downsides nobody talks about

Not everything is positive. Maintaining a headless architecture with WordPress requires technical discipline that a traditional setup doesn’t demand. You have to manage two infrastructures, sync deployments, and solve preview problems that are trivial in a monolithic WordPress. For small sites, the complexity cost probably isn’t worth it.

When do we recommend this architecture?

When the site has more than 100 pages, when there are multiple editorial collaborators, or when performance is critical to the business. If your site is a five-section landing page, you probably don’t need any of this.