AI Recommendation Builder That Had to Keep Up With Its Own Rule Book - 3 Case Studies

Quick answer

I built the admin builder for a WooCommerce recommendation plugin: a screen that shows a merchant their own storefront - product page, cart, checkout, shop - with editable markers at every point a recommendation block can appear. Three things had to be gotten right underneath that screen while it was being built: how many independent recommendation lists a single placement could hold, how many distinct rule types a merchant could filter by, and where two near-identical builder components should and shouldn't share code. Each problem needed its own answer, and all three are documented here.

The initiative

The plugin recommends products on a merchant's storefront based on rules - category match, price range, browsing behavior, purchase history, and more. The admin builder is where a merchant sets that up: pick a placement on their site, define one or more recommendation lists for it, and configure the rules and sort order for each. I built this screen and its underlying data model over about five weeks. It kept changing shape as requirements did - a placement went from holding one rule set to holding several independent ones, and the rule vocabulary kept growing past what the UI's early plumbing was built to handle. I moved to other work after that, and a teammate continued iterating on the builder from where I left it.

The case studies

When a Screen's Data Outgrows Its Own Update Code →

The state-management case study. What happens to a nested state model when a screen's data goes from "one rule set per placement" to "several independently editable lists per placement," and why I fixed how updates were written instead of reshaping the data.

Turning a Growing Rule Vocabulary Into Data Instead of Code →

The rule-vocabulary case study. The plugin's filter types kept growing - category, price, browsing behavior, purchase history, each with its own valid operators and timeframes. Here's how I moved that vocabulary out of component logic and into a single data table the UI reads from.

Two Rows That Look the Same and Aren't →

The component-boundary case study. Filter rows and sort rows looked like the same component wearing two hats - here's why we built them as siblings instead of one shared abstraction, and how I kept them from drifting apart as the codebase moved.

FAQ

What is a recommendation builder? It's the admin screen where a merchant configures product-recommendation logic for their storefront - which products to show, where to show them, and under what conditions - without writing any code. What does the plugin do? It's a WooCommerce plugin that recommends products across a store's product pages, cart, checkout, and shop pages, using rules based on category, price, browsing behavior, and purchase history. Who built this? I built the builder screen and its state and rule-configuration layer over about five weeks. I wasn't the only engineer on the plugin - the backend rule engine was owned separately - and a teammate continued developing the builder after I moved to other work. What changed after you moved on? The screen I built was later reworked by a teammate, including a different approach to the state layer than the one I'd used. Both approaches solve the same underlying problem from different angles - see the state-management case study for that comparison.

On this page