If I Built a Membership Plugin Today, I’d Build It for the Robots Too

A client asked me for a membership site the other day, and I did the thing I always do: I reached for MemberPress before my coffee had even kicked in. I’m a ride-or-die MemberPress guy. Have been for years. Blair Williams built it back in 2013, he’s still the CEO and chief product architect, and he’s quietly assembled one of the better teams in the WordPress space over at Caseproof. The product is good. The people are good. When someone says “membership,” MemberPress is my reflex, and reflexes usually mean something’s earned your trust.

So this isn’t a takedown. I want to say that up front, because what comes next probably reads like one if you skim it.

Here’s the thought that’s been rattling around my skull: if I sat down to build a membership plugin today, from a blank folder, knowing everything we now know about AI and agents and the tools sitting on my desk right now, I would build it completely differently. Not because MemberPress or any of the incumbents got it wrong. They got it right for the world they were born into. But that world moved, and most plugins haven’t caught up to the fact that they now have a brand new kind of user.

AI and WordPress Plugins. What are we talking about here?

When people talk about building software in the age of AI, they almost always mean one thing: “AI helps me write the code faster.” And sure, it does. I can scaffold a plugin with Claude Code or Codex in an afternoon that would’ve eaten a week two years ago. That’s real, and it’s great, and it’s also the boring part of the story.

The interesting part isn’t that AI writes your plugin. It’s that AI will use your plugin. An agent is now a user. Maybe your most important one. And almost nothing in the WordPress plugin world was designed with that user in mind.

Think about what a membership plugin actually is under the hood: users, subscriptions, access rules, transactions, cancellations, renewals. That’s a pile of structured data and a pile of actions you can take against it. For a decade we’ve exposed that pile to exactly one audience: a human clicking around in wp-admin. But a human clicking around is the slowest, most expensive way to interact with structured data ever. If I’m building today, I’m asking a different question on day one: how does a machine talk to this thing?

What I actually mean by a “platform plugin”

Before I get into the checklist, let me define a term I keep using around the office. I think of the good ones as platform plugins. Not a plugin that does one job, but a nucleus of functionality you can bolt other things onto. It ships with all the core plumbing you’d need for its domain (in this case: memberships), and then it gets out of your way and lets you build and scale on top of it.

WooCommerce is the obvious example everyone reaches for. It’s not really “a shopping cart,” it’s a commerce foundation that a thousand other things plug into. MemberPress does a lot of this already. So the real question isn’t “platform or not.” It’s: who and what is the platform open to? Humans only? Or humans, other plugins, and the agents we’re all going to be running by this time next year?

My answer is all three. Here’s what that looks like in practice.

The checklist I’d build against

1. It speaks the WordPress Abilities API from day one

This is the big one, and it’s the reason I’m even writing this post now instead of a year ago. WordPress core shipped the Abilities API in 6.9 (the JavaScript side landed in 7.0), and it’s the closest thing WordPress has ever had to a universal translator. The idea: core, themes, and plugins all register their capabilities as “abilities” in one central registry, each with a name, a description, an input schema, an output schema, and a permission check. A one-stop shop for what your plugin can actually do, described in a way that other software (and AI) can understand without reading your source code.

If I’m building a membership plugin, every meaningful action becomes an ability: membership/grant-access, membership/cancel-subscription, membership/list-active-members. Register those, flag the destructive ones as destructive, and suddenly other plugins can interoperate with mine cleanly, and an agent can discover what my plugin does instead of me having to document every corner of it by hand. That’s not a nice-to-have anymore. That’s table stakes for anything built in 2026.

2. A real REST API, out of the box, for full CRUD

Not an afterthought. Not a paid add-on. A first-class, versioned REST API where I can create, read, update, and delete every core object the plugin manages. Members, plans, subscriptions, rules, all of it. Stable namespaces (/wp-json/membership/v1/), consistent JSON shapes, predictable error codes a machine can branch on. If you can do it in the admin, you can do it over the API. Full stop. The admin UI should just be one client of that API, not the only door into the data.

3. WP-CLI commands, because that’s where the agents live

Here’s a very 2026 sentence: I want my membership plugin drivable from the command line, because that’s where tools like Claude Code and Codex do their best work. When I’m knee-deep in a site migration or debugging a busted renewal, I don’t want to click through fourteen admin screens. I want wp membership list-subscriptions --status=active --format=json and I want an agent to be able to run that, read the output, and do something useful with it.

Structured, parseable output. Explicit confirmation flags on anything destructive. This is how I already work on our own stack (a lot of the little plugins powering this very site were built and are driven exactly this way), and it’s genuinely wild how much faster the work goes when your tools assume an agent might be holding the wheel.

4. It’s MCP-ready, so agents can actually reason about it

The Model Context Protocol is the standard that lets an AI safely reach into external tools and data. Automattic already ships a WordPress MCP plugin and an MCP adapter that turns those Abilities I mentioned earlier into MCP tools an agent can call. So if I’ve done step one properly (registered clean abilities), I get most of the MCP story almost for free. Register the ability, mark it public, and now an agent can discover it, understand it, and execute it with the right permissions. That’s the whole game: not “AI bolted on,” but a plugin whose capabilities are legible to software from the ground up.

5. Events and webhooks that mean something

Membership is an event machine. Someone signs up, upgrades, churns, fails a payment, comes back. Every one of those moments should fire a clean, well-documented webhook with a structured payload, so the rest of your stack (your CRM, your email tool, your custom automations, an agent watching for churn signals) can react without polling the database like it’s 2012. Half the interesting AI-and-automation work we do with membership sites only works because the underlying data emits good events. Starve the events, and you starve everything downstream.

6. Docs written for machines as much as humans

Last one, and it’s the least sexy: write your hooks, filters, and API contracts down precisely, and version them. AI coding assistants read documentation literally. If your docs are vague, an agent will guess, and it’ll guess wrong in ways that are expensive to unwind. Clear, unambiguous, versioned docs used to be a courtesy to the developer down the hall. Now they’re a courtesy to every agent that’s ever going to touch your plugin, which is a much larger and less forgiving audience.

Here’s the part I’m actually excited about

Say I built the plugin exactly like that. Every checklist item, done. What does a random Tuesday look like then?

I open Claude (or ChatGPT, whatever you’ve got wired up), because the plugin exposes its abilities through an MCP server. And I just talk to it. Something like:

“Build me a membership. Call it Pro. Forty-nine bucks, billed every three months. Give members access to everything in the Coaching and Templates categories, but keep the Vault content locked to a higher tier. Spin up a thank-you page after checkout, and a members-only landing page.”

And then it goes and does it. Not a mockup. The actual membership, the actual access rules, the actual pages. Because every one of those things is an ability the agent can discover and call: create the plan, set the price and the billing interval, wire up the access rules, generate the pages. I never touched a settings screen. I never had to hunt through six tabs to find where recurring billing lives. I described what I wanted in a couple of sentences and the plugin built it.

Then I keep going, because it’s a conversation. “Actually, add a monthly option too.” “Throw in a coupon for 20% off the first cycle.” “Now show me how many people are on the quarterly plan.” Each one is another call against the same clean set of abilities. No context switching, no documentation dive, no clicking around hoping I’m on the right screen.

That’s the whole pitch, and I’ll be honest that it sounds a little like sci-fi when you write it out. But none of it requires magic. It requires a plugin whose capabilities are legible to an agent. The Abilities API gives you the vocabulary, MCP gives you the conversation, and the underlying REST and CLI layers mean the agent has real, permissioned actions to take rather than guesses to make. Build the plumbing right and the natural-language part mostly falls out of it.

Here’s the kicker, and it’s the part that actually matters for our clients: this is also how you hand a membership site to someone who is never, ever going to learn your admin. “Tell it what you want” beats a 40-page onboarding doc every single time. The agent becomes the interface, and the settings screen becomes the thing you only open when something’s genuinely weird.

So am I building a MemberPress killer?

No. I’m really not. And I want to be straight about that instead of pretending this post is a product announcement it isn’t.

Blair and the Caseproof crew are very good at what they do, they’ve got real resources behind them now as part of Syed Balkhi’s Awesome Motive family, and building a membership platform to production quality is a years-long slog I have zero interest in signing up for. I’d rather they keep doing it and keep doing it well. If anything, I’d love to see the incumbents lean all the way into the Abilities API and MCP, because when the big platform plugins get agent-friendly, all of us building on top of them win.

The point of the exercise isn’t the membership plugin. It’s the question underneath it. When you build anything in WordPress now, whether it’s a plugin, a client site, or one of those membership builds that keeps a business running, you get to decide who it’s built for. The old default was “a human at a keyboard.” The new default has to include the machines that human is going to hand the keyboard to.

That’s the shift. It’s not that AI writes the plugin. It’s that the plugin has to be built so AI can actually do meaningful work with it. And most of them, even the great ones, even the LMS and membership tools I recommend every week, aren’t there yet. That gap is the whole opportunity.

I could be wrong about how fast this lands. I’ve been wrong about timelines before (I’m a little shitty at predicting the future). But the direction feels right, and I don’t think it reverses. If you’re building a plugin right now and you’ve only been thinking about the human clicking around in the admin, that’s the thing I’d go rethink this week.

Building something with this in mind, or think I’m overcooking it? Tell me where I’m wrong. I actually want to know.