Modelling a catalogue and its variants without regret
The product model is the decision that quietly determines how hard everything else will be. Stock, pricing, search facets, marketplace feeds and returns all read it, and all of them inherit any confusion in it.
The single most common mistake is modelling the thing you photograph rather than the thing you ship.
The distinction that matters#
| Concept | What it is | What it must own |
|---|---|---|
| Product | The thing a customer chooses | Title, description, images, category |
| Variant | The thing you actually ship | SKU, price, stock, weight, barcode |
| Option | The axis of choice | Size, colour — with a fixed value list |
| Bundle | Several variants sold as one | Its own SKU and its own stock rule |
Rules that save a rebuild#
- Every sellable thing has a SKU. If it cannot have one, it is not sellable on its own.
- Option values come from a controlled list, never free text. "Blue", "blue" and "Navy Blue" become three facets otherwise.
- Price and stock live on the variant, always, even when today all variants share a price.
- Media can belong to a variant, not only to the product — colour variants need their own images.
- Do not encode meaning in the SKU string that is not also a real field.
Things that look like variants and are not#
Personalisation (an engraved name), quantity breaks, and bundles are often forced into the variant model because it is the nearest hammer. They belong elsewhere: personalisation as line-item data, quantity breaks as pricing rules, bundles as their own product with a stock policy.
If your variant count multiplies past a few hundred for one product, you have modelled something that is not a variant.
Attributes, categories and the feed you will need later#
Marketplaces, comparison engines and your own faceted search all want structured attributes: material, dimensions, compatibility. Capture them as fields from the beginning. Extracting them from prose descriptions two years later is a data project nobody enjoys.
Frequently asked questions
Should price live on product or variant?
Variant. Even if every variant costs the same today, that will change and the migration is unpleasant.
How do I handle made-to-order personalisation?
As line-item data captured at add-to-cart, not as an explosion of variants.
When should attributes be structured fields?
Immediately. Faceted search, feeds and filters all need them, and prose cannot be filtered.
product catalogue modellingproduct variantssku structureecommerce data modelproduct attributes
