ProductBay

The problem

B2B and wholesale WooCommerce stores don’t shop the way retail customers do. A buyer ordering forty SKUs at once doesn’t want to click into forty product pages and add each one to the cart individually — they want a dense, scannable table: SKU, price, stock, quantity field, add to cart, repeat. WooCommerce’s default catalog is built for browsing one product at a time. It has no answer for “give me something I can order from like a spreadsheet.”

ProductBay is built to answer exactly that, and nothing more. It renders a fast, filterable product table on top of a WooCommerce catalog — sortable columns, bulk quantity inputs, bulk add-to-cart — for stores where the buyer already knows what they want and just needs to move quickly.

ProductBay is a WPAnchorBay product. I’m the plugin’s developer there, and I own its full lifecycle — architecture, code, the WordPress.org submission, the Pro edition, the documentation, and support.

Architecture

The plugin splits along the line WordPress plugins usually split along: PHP does what PHP is good at, React does what React is good at.

The backend is plain PHP — WooCommerce and WordPress hooks, REST endpoints that expose the product data the table needs, capability checks, and settings persistence. No framework beyond WordPress core; a commercial plugin that has to run on other people’s servers, in unpredictable hosting environments, for years, is not the place to bet on a PHP framework trend.

The admin interface and the front-end table are React and TypeScript, built with @wordpress/scripts — the same tooling WordPress core uses for Gutenberg, so webpack, JSX, and modern JS transforms are configured for a WordPress plugin without my having to maintain that configuration myself. The result is a settings screen and a table interaction model that feels like a modern app rather than an options.php form from 2012, while still shipping as a plugin that requires zero build step from the end user.

Shipping to WordPress.org

Free distribution for a WordPress plugin runs through one door: the WordPress.org Plugin Directory review process. It checks for security (sanitization and escaping on every input path, capability checks on every action, nonces where they’re required), licensing (everything shipped has to be GPL-compatible), and a readme.txt that actually matches what the plugin does. There’s no partial credit — it either passes, or it comes back with specific, itemized objections, and you fix and resubmit.

Preparing ProductBay for that review meant a targeted pass through the codebase looking specifically for what a reviewer looks for: every $_POST/$_GET read sanitized, every output escaped, every AJAX and REST handler capability-checked, no bundled library without a clear, license-compatible reason. It’s a genuinely useful forcing function — the review isn’t a gate you talk your way through, it’s an adversarial second pass over your own security assumptions, done by someone with no context on your code.

ProductBay ships free through the WordPress.org plugin directory, with a Pro edition and full VitePress documentation alongside it.

Building the Pro edition

The free plugin has to stand on its own — reviewers and users both expect that, and a free plugin that’s a crippled demo gets flagged and earns bad reviews. So ProductBay Pro is architected as an addition, not a repair: it hooks into the same data layer and extends the table — deeper filtering, more presentation control — rather than unlocking functionality that was artificially disabled in the free version.

That constraint — free must be genuinely complete, Pro must be genuinely additive — shapes the codebase more than almost anything else. Every feature decision starts with “does this belong in core, or is it a Pro-tier extension,” and both editions share the same underlying REST contracts so Pro never forks the data model.

Writing the docs

ProductBay ships with a full documentation site built on VitePress — installation, configuration, every filter and shortcode, troubleshooting, and Pro-specific setup. Writing the docs after building the plugin, rather than alongside it, turned out to be the wrong order: undocumented decisions are easy to make and hard to reconstruct a week later. The docs site is now the first thing I update when a feature changes, not the last.

What running a real product taught me

Building a plugin and running one are different jobs. Building rewards deep focus and clean code. Running rewards responsiveness — to support requests, to WordPress core updates that quietly break an assumption, to a WooCommerce version bump that changes a hook signature underneath you. ProductBay is the first thing I’ve shipped where “done” isn’t a milestone; it’s a maintenance commitment with no end date. That’s the actual lesson: a product isn’t a project with a launch date — it’s a project with a launch date and no closing date. The cycle is already repeating: CartBay, an abandoned-cart recovery plugin, is the second one I’ve shipped to WordPress.org for WPAnchorBay.