A license-key catalogue grows the way most commerce catalogues do: fast, and not always in the order you'd plan it in. Increddy sells across dozens of platforms, genres, editions, and regions, categories that weren't all known on day one and that keep changing as the catalogue grows. Modeling that without duplicating content per product, and without breaking a URL every time a product gets renamed, was a content-architecture decision as much as a commerce one.
The duplication trap in a digital-goods catalogue
The naive approach treats genre, platform, edition, and region as text fields on each product. It works fine for the first fifty products. It breaks down the moment a platform name needs correcting, a region needs splitting into two, or a new facet needs adding retroactively across an existing catalogue, because now every affected product needs editing one at a time, and a typo in one product's free-text field silently drops it from a filter that depends on exact matching.
Taxonomy as modules, not tags
Increddy models genre, platform, edition, and region as their own Medusa modules, each one a referenced entity rather than a string copied onto every product. A product links to a platform, it doesn't restate its name. Rename the platform once and every product referencing it is correct immediately, with no batch edit and no risk of a typo creating an orphaned, unfilterable variant of the same category.
One activation guide, many products
The same duplication problem shows up again in support content. Dozens of products on the same platform need near-identical activation instructions: how to redeem a key on that specific storefront, what to do if redemption fails, where to find the activation page. Writing that per product means the same instructions exist in dozens of places, and an edit to the process needs the same edit repeated dozens of times. Increddy serves activation guides from a shared, admin-editable library instead, referenced by product rather than duplicated into it, so updating a platform's redemption steps once updates it everywhere that product links to it.
Catalogue growing faster than your content model can keep up?
If updating one fact means editing it in twenty places, that's usually a modeling problem, not a content-volume problem. We'll look at what's actually duplicated and what a shared reference would fix.
Talk to an engineer →Renaming a product without breaking its URL
Products get renamed: a publisher changes an edition's name, a typo gets fixed, a listing gets clarified. Every rename is a URL change, and every URL change is a broken link somewhere, a bookmark, a paid-ad landing page, a search result that hasn't recrawled yet, unless something catches the old URL and forwards it. Increddy keeps an old-URL redirect table: a lookup that checks previous slugs before falling back to a real not-found page, so a renamed product's old link keeps resolving instead of quietly turning into a dead end on a storefront that's actively running paid traffic to specific product pages.
The rule
Model anything that repeats across products, a category, a set of instructions, a region, as a referenced entity with one source of truth, not as text copied into every product that needs it. And treat a product rename as a URL-stability problem to solve deliberately, with a redirect layer, not as something that'll probably be fine. For the backend this taxonomy lives in, see how we replaced Shopify's backend without touching the frontend. We design content models like this under Medusa development and Directus development engagements.