A 27x catalog scale-up.

01 / The Challenge

Onboard 8000 new products in a catalog of 300

Mula was expanding its merchandise catalog from 300 products to 8,000, on a tight timeline. My job was to design the taxonomy that would govern how all of them were navigated, across two substantially different catalogs and three supplier structures that had never been unified.

Eight thousand products can't be crammed into a taxonomy built for three hundred. This needed a new catalog architecture, designed from the ground up to host a fundamentally different scale.

02 / The Architecture Decision

No time for a fresh build

The first instinct was to map everything to Mula's category tree. A few days cross-referencing the new supplier catalogs made it clear that our current category tree and the new ones had fundamentally different scopes, and mapping to Mula's was not an option.

The time pressure did not allow us to build a new taxonomy from scratch to support such a vast amount of products. The smarter move: review the new supplier catalog taxonomies, assess which one had the strongest fundamentals, use it as the reference, and map the other catalogs onto it.

03 / The Approach

Mapping categories across trees was not enough

With the reference taxonomy defined, category mapping was supposed to handle most of the volume. Nevertheless, a few days into the task revealed that it would not be that simple.

The problem: supplier category names were meaningless as mapping rules. A broad category like Kitchen Accessories did not have a clean mapping. In practice, the only way to understand its actual scope was to open that category in the supplier's catalog and check every article inside, often belonging to several categories on the reference tree. What looked like one mapping decision was in reality dozens, each item assessed individually.

At scale that meant thousands of individual category decisions made downstream by people without the taxonomy knowledge I had, each one potentially degrading the new taxonomy's integrity. The consequences of handing the manual mapping to Catalog Management, and the risk of progressive miscategorisation, were concrete and expensive:

04 / The Solution

Automate product categorisation using AI

I wanted to test whether product categorisation could be automated instead of being carried out manually. The idea was to feed basic product information, name, description, and image, into an agentic pipeline that assigned each product to its correct 3-level category node.

Four problems, four lessons

Four distinct problems surfaced across iterations, each one producing a unique learning and driving a complete shift in engineering strategy:

Impact

The resulting automation transformed an operational bottleneck into a permanent infrastructure asset. Moving from manual tagging to a decoupled n8n pipeline permanently protected the integrity of the taxonomy while radically optimising time and capital for both current and future product onboardings:

Learnings

Prompt instability turned out to be a diagnostic signal, not a tuning problem. When every fix shifted the errors rather than eliminating them, the architecture was the issue, not the instructions. Recognising that earlier, before the accumulated iteration cost, is now the first thing I check. And the input data matters as much as the model: the HTS code outperformed images not because it was cheaper to process, but because it was a more precise signal for the task.

Execution used to be where good design quietly degraded: a catalog architecture designed with care, handed to a manual process, eroded by a thousand small decisions made without the full picture. The classifier closed that gap, not just for this project, but for every onboarding that follows.