A week ago I wrote about building WP Career Board from scratch on the block editor, the Interactivity API, and a PHP 8.1 codebase. That post was the engineering story. This one is the ecosystem story, and it is the reason I took on a job board plugin in the first place.

WP Career Board Pro is live. We pushed the marketing launch on the Wbcom blog this week, and the product page is open for business. But the product launch is not what I want to write about. I want to write about the bet that sits underneath it.

WP Career Board Pro admin dashboard hero
WP Career Board Pro, running on a real WordPress install.

Before the long read, here is the six-tile version of the story for anyone who is skimming. The rest of this post is the extended cut.

Carousel tile 1: Hire the way your community works
Carousel tile 2: From applied to hired
Carousel tile 3: Publish, filter, expire
Carousel tile 4: Know every applicant
Carousel tile 5: Try the live demo
Carousel tile 6: Same PHP, same MySQL, no lock-in
The launch in six tiles: cover, pipeline, listings, candidates, CTA, and the stack.

The bet is not a plugin. It is a complete WordPress stack.

Here is the thesis I have been quietly acting on for the last two years. WordPress is not losing. It is shedding the work it was never very good at. The slick marketing site moved to Framer. The SaaS dashboard moved to a headless React app. The feedback board moved to Canny. The community forum moved to Circle. The job board moved to Workable or Greenhouse.

Every one of those moves made individual sense. Added together, they carved out a WordPress that does less every year while the rest of your stack gets more complex, more expensive, and more tied to vendors you did not pick.

I think that trend is about to reverse. Not for everyone, and not for every tool. But for the teams that built on WordPress because they wanted ownership and simplicity, the drift toward a dozen SaaS dashboards is starting to feel like a mistake. The bills are growing. The integrations are fragile. The data is scattered. And the tools on top of WordPress are finally good enough that a lot of those SaaS services no longer have a real edge.

WP Career Board is one bet on that reversal. It is not the only one.

The four pieces we are building, and why each one reinforces the others

At Wbcom we are building a set of products that are meant to add up to something bigger than any of them. Each one is useful on its own. The real value is what happens when a single site owner runs more than one of them at the same time. Here is the current map.

Reign Theme: the community operating system

Reign is our flagship community theme. It has carried BuddyPress, BuddyBoss, LearnDash, WooCommerce, and bbPress on its back for years. If you want to run a membership site, a learning platform, a forum, a marketplace, or any combination of those inside WordPress, Reign is the layer that holds them all together visually and functionally. It is the operating system we build everything else on top of.

BuddyX and BuddyX Pro: the developer-friendly alternative

BuddyX is the lightweight, FSE-ready community theme for teams that want a cleaner codebase and full Site Editor compatibility. Same audience as Reign in many ways, different shape. Some customers want an opinionated turnkey theme (Reign). Others want something closer to a block canvas (BuddyX Pro). We build both so we do not have to compromise on either.

Jetonomy: a native WordPress forum plugin

Jetonomy is our bet that a modern WordPress forum is worth building rather than accepting Circle or Discourse as the only serious options. The same argument we are making with WP Career Board, we are making with Jetonomy. Self-host. Own the conversation. Plug into the member identity you already have. Stay inside the WordPress admin. Do not pay per-seat fees for a discussion your community is having about your own product.

WP Career Board: jobs inside the community

And now WP Career Board. Jobs, applications, candidates, employer dashboards, resumes. Same philosophy as the other three. Same stack. Same opinion about where the data should live. The free version shipped a week ago. Pro is the big release I am writing about now.

Each of those products is useful on its own. That matters, because a bundle only works if the parts stand up alone. But run two of them on the same site and something interesting happens. Run three of them and it becomes obvious why we are doing this.

The unlock: shared infrastructure across plugins

The most important thing I have learned building plugins for the last decade is that the stuff your users see is not where the leverage is. The leverage is in the infrastructure that sits underneath every plugin you ship, because that is the thing that compounds.

Two concrete examples from what we shipped this week.

The Wbcom Credits SDK

I wrote about this in the previous post, but the point is worth repeating. The Credits SDK is an append-only ledger that any plugin can bundle. Topup, hold, deduct, refund. Gateway adapters for WooCommerce, Paid Memberships Pro, and MemberPress. Your plugin never touches payment processing. The SDK just manages the credit balance.

WP Career Board Pro is the first plugin to ship with it, because employers who post jobs need a way to pay us, and we did not want to rebuild that plumbing again. Jetonomy will use it for premium group creation and paid pinning. A future service marketplace plugin will use it for listing fees. Every time we add a credits-aware plugin to the ecosystem, the infrastructure we already wrote gets reused, and the user’s single credit balance covers more features.

One credit balance across multiple plugins. That is the kind of unlock you only get from thinking in ecosystems, not in products.

The theme bridge layer

Every Wbcom plugin detects Reign and BuddyX Pro at runtime and bridges to them. CSS custom properties, colors, fonts, spacing all inherit from the theme’s design tokens. Zero custom CSS needed on the plugin side when the theme is one of ours. Zero theme overrides needed on the user side.

This is the kind of integration that is tedious to do for one plugin and powerful once you have three. The next plugin we ship inherits the bridge for free. The theme’s next major release updates every plugin at once. Design system changes propagate. That is how you get a coherent product surface across a portfolio without hiring a design team per plugin.

Why WordPress-native matters more in 2026 than it did in 2020

Here is the contrarian position I am taking, and it is the one most likely to age badly if I am wrong. I think the SaaS-for-every-problem era peaked two years ago, and the reversal is quiet but real.

Comparison table: WP Career Board against hosted SaaS job boards and legacy WordPress plugins
WP Career Board against hosted SaaS and legacy plugins, capability by capability.

The table above is the simple version of the argument, and we broke it down more formally on the Wbcom blog this week. But the longer version is worth saying out loud.

The SaaS bill is not the problem. The dependency graph is.

People complain about SaaS pricing, and they should. But the thing that actually hurts when you try to run a small business on top of a dozen SaaS products is not the monthly line items. It is the dependency graph. Every new tool you add is a new vendor whose roadmap you do not control, a new integration that can break on their next deploy, and a new set of data that lives somewhere you cannot query.

When you run a WordPress site and add a hosted job board, you are not just paying for the job board. You are also agreeing that the next time you want a report that crosses your job board data with your course completion data, you will need to build a middleware layer to pull from two APIs, join them in memory, and hope neither changes. That cost does not show up on the invoice.

WordPress has gotten quietly better at being a platform

The other half of the reversal is that WordPress itself has become genuinely capable of running the kind of application you would have outsourced in 2020. The Interactivity API gives you client-side behavior without jQuery or a separate framework. The block editor gives you a real composition layer. The REST API gives you standardized data access. Custom post types and custom tables cover most schemas. The admin is still the admin, but the plugin surface around it is much sharper than it used to be.

Five years ago, building a serious job board on WordPress meant fighting the platform. Today, it means using the platform the way it was designed. The work goes into the product instead of the plumbing.

What a week of launching has taught me

We shipped the free plugin first, wrote the engineering post, opened the store page, and watched what happened. A few things jumped out that I did not expect, or at least did not predict correctly.

The first question was always about data, not features

I expected early conversations to focus on the Kanban pipeline or the AI job description generator. Neither was the top question. The top question, asked in different ways by different people, was some variant of: “Where does the candidate data actually live, and can I get it out if I want to?” That is a data ownership question dressed up as a feature question, and the people asking it were mostly agencies and association operators who had been burned by a SaaS migration before.

The answer was easy because we planned for it. Custom post types and documented custom tables. Full REST API. Exportable through WP-CLI. No lock-in. But the frequency of the question was a surprise, and it told me that the ownership pitch is stronger than the feature pitch for a non-trivial slice of the market.

Community sites want jobs more than marketing sites do

The interest did not come from WordPress marketing sites trying to add a hiring page. It came from BuddyPress and BuddyBoss community operators, training platforms running LearnDash and LifterLMS, and professional associations running membership sites. All of them had one thing in common. They already had an identity layer for their members, and what they wanted was to bolt a job board onto the community without sending members to a third-party site and losing the context.

This is exactly the shape of customer our ecosystem is built for, and it validated the decision to ship with deep BuddyPress integration from day one instead of treating it as a later release.

The “same stack” story landed harder than the “modern stack” story

I thought the headline would be “block-native, zero jQuery, Interactivity API”. That is true and it matters, but the phrase that actually pulled people in was simpler. “Same PHP. Same MySQL. No lock-in.” People do not want to learn a new stack. They want to reuse the one they already know. The modern engineering stack is a means, not an end, and I should have led with the end.

That is a lesson I will keep applying to every future launch in the ecosystem.

The boring work is the real work

One thing I do not talk about enough in public, probably because it does not make for a good launch post, is how much of running a plugin business is maintenance that nobody sees. People think we ship a plugin, sell some licenses, and move on to the next one. The reality is closer to a long-running service contract.

Every WordPress release cycle, the plugin team has to re-test every plugin against the new core. Every PHP minor version, we bump our matrix and re-run PHPStan. Every time a popular plugin in the wider ecosystem ships a breaking change, we pick up the pieces for the subset of our users who run both. A lot of the commits you do not see are the ones that keep the lights on.

That is actually why building in ecosystems works. When I invest an afternoon in making the theme bridge layer smarter, every current plugin gets better and every future plugin starts from a better baseline. When I spend a week on the Credits SDK, I am writing code once and using it five times over the next two years. The boring work compounds if you are building in a portfolio and burns out if you are building in isolation.

This is also the argument I make to myself when I am tempted to ship a standalone product on a trendier stack. Yes, I could write something greenfield in a weekend. What I could not do, not in a year, is recreate the accumulated leverage of building inside a system I already know inside out.

How I decide what to build next

People sometimes ask how we pick the next plugin to build. There is no formal framework, but there is a rough shape the decision takes, and it is worth spelling out because it explains why WP Career Board was next and not something else.

  • Does it close a gap in the ecosystem we are building? If a capability is missing from the self-contained WordPress stack we are betting on, that is a reason to build it. A feedback board, a forum, a job board, a service marketplace. These are the kinds of shapes that fit.
  • Do our existing customers already ask for it? Our support inbox is the best market research we have. If Reign customers are asking how to run a job board on top of their community site three or four times a month, that is a signal.
  • Is the existing option bad enough to justify the work? If there is already a great plugin in a niche, we do not build a competitor. We would rather write an integration layer than duplicate work that someone else is doing well.
  • Can we build it on our existing infrastructure? The Credits SDK, the theme bridge, the shared REST patterns, the CI pipeline. If a new plugin can reuse 40 or 50 percent of what we have already built, the math gets dramatically better than starting from zero.
  • Will it compound with the other plugins? The most important question. A plugin that only makes sense in isolation is worse than no plugin at all. A plugin that makes every other plugin in the portfolio more valuable is a strategic asset.

WP Career Board scored well on all five questions. That is why we spent the last year building it. It is also why the next plugin on the list is one I am not ready to announce yet but will fit the same frame, share the same infrastructure, and ship into the same community of users that is already running our current products.

What is next for the ecosystem

The product roadmap for WP Career Board Pro is on the Wbcom post and the store page. Here is the ecosystem roadmap, which is the list I pay more attention to day to day.

  • Shared identity across plugins. A single user signs in once and is recognized as an employer in WP Career Board, a member in BuddyPress, and a purchaser in WooCommerce, with a unified profile surface.
  • Shared notifications. One notification center that aggregates events from every Wbcom plugin on the site, rather than a notification panel per plugin.
  • Shared analytics. A common dashboard that reports across community activity, course completion, job applications, and forum engagement.
  • More plugins on the Credits SDK. At least two more plugins will adopt the SDK this year. The credit balance a user buys for jobs will cover other premium features across the portfolio.
  • Deeper Reign and BuddyX Pro integration. Automatic theme-aware templates for every Wbcom plugin, maintained by the theme team so individual plugin teams stop duplicating the work.

None of that is revolutionary. Ecosystems are built by consistently doing the boring, compounding work. The revolutionary part is deciding to do it at all, when the default incentive is to ship features and ignore the seams between them.

If you are interested in any of this, here is where to go next.

View WP Career Board Pro
Try the live demo

Why I keep doing this

Every time I ship a plugin on WordPress in 2026 instead of on a modern SaaS stack, someone asks why. Why not build a standalone job board as its own company? Why not use Next.js and Supabase and ship something that feels more 2026 and less 2014?

The honest answer is that I like the shape of the constraint. WordPress makes me think in ecosystems. It makes me build things that have to coexist with the other things on a user’s site, that have to respect the theme, the database, the admin, the muscle memory the user already has. That constraint is the reason the code gets better over time instead of worse. It keeps me from building a brittle thing that only makes sense when nothing else is nearby.

And the pragmatic answer is that the people I am building for are already on WordPress. They have been on WordPress for ten years. They are not going to move. The most useful thing I can do for them is meet them where they are and make the platform they already chose work better.

If any of this resonates, run the demo, skim the product page, and tell me what you think. The free plugin is on the WordPress.org directory and the source is on GitHub. I am easy to reach. The feedback from the first week was already good, and the second week is the one that gets shaped by the people who read this far.