DEV Community

Cover image for Headless WordPress Isn’t Enough (Here’s What’s Missing)
Drew Marshall
Drew Marshall

Posted on

Headless WordPress Isn’t Enough (Here’s What’s Missing)

When I first moved to headless WordPress, it felt like a huge upgrade.

No more theme constraints.
No more mixing PHP templates with business logic.
A clean separation between frontend and backend.

It worked.

But after a few projects, I started noticing a new problem.


The New Problem

Headless WordPress removes one layer of complexity…

…but it shifts that complexity somewhere else.

Now your frontend is responsible for:

  • fetching data
  • shaping responses
  • handling auth
  • managing consistency across endpoints

And if you build multiple frontends?

You repeat that logic.

Every. Time.


What Headless Actually Solves

Headless WordPress is great at:

  • decoupling the UI
  • improving performance (especially with SSG)
  • giving frontend flexibility

That’s all real value.

But it doesn’t solve:

Where does application logic live?


The Missing Layer

Most setups look like this:

Frontend → WordPress REST API
Enter fullscreen mode Exit fullscreen mode

Simple.

But also…

fragile.

Because the frontend becomes:

  • data layer
  • logic layer
  • presentation layer

All at once.


What I Started Doing Instead

I introduced a middle layer.

Frontend → Application Layer → WordPress
Enter fullscreen mode Exit fullscreen mode

That layer is where:

  • data access is standardized
  • logic is centralized
  • behavior becomes reusable

Enter KiwiPress

KiwiPress is my attempt to define that missing layer.

Instead of every frontend talking directly to WordPress…

They talk to structured services like:

  • WPRead
  • WPCreate
  • WPUpdate
  • WPDelete

Each one has a clear responsibility.

No duplication.

No guessing where logic lives.


What This Changes

Before

  • every frontend reimplements logic
  • inconsistent data handling
  • harder to scale across projects

After

  • one source of truth for behavior
  • cleaner frontends
  • easier to swap rendering strategies

Now I can move between:

  • static builds
  • SPAs
  • server-rendered apps

…without rewriting core logic.


Where Static Site Generators Fit

This doesn’t replace SSG frameworks like:

  • Next.js
  • Astro
  • Gatsby

If anything, it complements them.

SSGs handle:

  • rendering
  • performance
  • delivery

KiwiPress handles:

  • structure
  • logic
  • consistency

The Bigger Idea

Headless WordPress is a step forward.

But it’s not the final step.

If WordPress becomes the data layer

Then we still need something to define the application layer.

That’s what I’m building toward.


Final Thought

Headless solves separation.

But structure is still your responsibility.

And that’s where things usually fall apart.

Top comments (0)