I Stopped Fighting WordPress… So I Rebuilt How I Use It

I’ve built enough WordPress projects to notice a pattern.

They all start clean.

Then slowly:

• plugins pile up
• logic creeps into templates
• APIs get scattered
• and “just make it work” becomes the architecture

At some point, you’re not building a system anymore—you’re managing chaos.

And the frustrating part?

It’s not really WordPress’ fault.

The Real Problem

WordPress tries to be everything:

• CMS
• backend
• frontend
• plugin system
• templating engine

So naturally, everything ends up mixed together.

Routes know too much.
Templates do too much.
Plugins patch too much.

There’s no clear boundary between:

• data
• behavior
• execution

That’s where things break down.

The Shift That Changed Everything

Instead of treating WordPress like the application…

I started treating it like a data source.

That single shift changes everything.

Now:

• WordPress manages content
• My system manages behavior
• The frontend becomes fully flexible

Introducing KiwiPress

KiwiPress is an application layer on top of WordPress.

It doesn’t replace WordPress.

It organizes how you use it.

The goal is simple:

Separate what WordPress stores from how your app behaves.

How It’s Structured

KiwiPress sits between your app and WordPress and splits responsibilities clearly:

• Seltzer → handles routes and request lifecycle
• Nectarine → parses config and API structure
• KiwiPress → owns WordPress-specific behavior

Inside KiwiPress, everything is broken into focused services:

• WPCore → handles communication with WordPress
• WPRead → fetches data
• WPCreate → creates data
• WPUpdate → updates data
• WPDelete → deletes data
• WPAuth → handles authentication
• WPSync → handles migration, backup, and syncing

Each part has one job.

Nothing leaks.

What This Looks Like in Practice

Instead of stuffing logic into routes or templates…

You delegate.

const wpread = new WPRead();

const route = {
  method: "GET",
  path: "/users/:email",
  handler: () => wpread.getUserByEmail()
};

The route doesn’t know how WordPress works.

It just asks for data.

Why This Matters

This approach gives you:

1. Clarity

You always know where logic lives.

2. Flexibility

Your frontend can be anything:

• custom UI
• SPA
• static site
• hybrid

3. Portability

If you ever move away from WordPress, your app doesn’t collapse.

4. Maintainability

No more hunting through plugins and templates to understand behavior.

A Better Way to Use WordPress

I’m not trying to replace WordPress.

I’m trying to use it correctly in modern systems.

WordPress is still great at:

• content management
• admin workflows
• ecosystem

But your application logic shouldn’t live inside it.

Where This Is Going

KiwiPress is part of a larger system I’m building focused on:

• contract-driven architecture
• modular app engines
• vendor-neutral systems

This is just one piece.

But it’s the first one that feels like a real product.

Final Thought

WordPress isn’t broken.

We just keep asking it to do too much.

Split the responsibilities…

…and suddenly everything gets a lot simpler.