Categories: one tree, not three
A category answers the question "what kind of product is this at all". A t-shirt, a drill, cat food. There should be one category tree, and every product needs one primary place in it. Otherwise you can't say how many products you have, and search engines end up with ten URLs holding the same content.
The classic mistake is pushing things into categories that aren't categories. "Sale", "New arrivals", "Gifts under 50", "Brand X" - those are collections: dynamic selections based on product attributes. The difference is practical. A category has to be filled by hand; a collection assembles itself and doesn't break when the promotion ends.
Keep the tree within three levels. Past that you're asking people to click five more times, and they give up and go to site search instead. If three levels aren't enough, what you probably need isn't more subcategories - it's filters.
- One primary category per product; every other placement is a collection or a filter.
- Name categories the way a buyer names the product, not the way it's labelled in your inventory system.
- Every category needs its own URL and its own heading: /catalog/drills/, not /catalog/?cat=17.
Attributes and filters: a filter is a consequence, not a separate feature
You can't bolt a filter on. A filter appears on its own once products have structured attributes. As long as size lives inside a text description as "size 42-44, cotton blend", there's nothing to filter - the data doesn't exist in machine-readable form.
So the first step isn't picking a filter design, it's building an attribute table. For each category: a list of properties with name, type (number, option from a list, yes/no) and unit of measure. Drills have wattage, chuck type, reverse function. T-shirts have size, colour, fabric. Different categories have different sets, and that's fine: filters should be tied to a category, not shared across the whole store.
You can check your readiness for filters in a minute. Try exporting products into a spreadsheet where each attribute is its own column with consistent spellings. If the colour column contains "black", "Black", "blk" and "noir", the filter will show four different colours instead of one. Controlled value lists have to exist up front.
One more thing people remember too late: a product count next to each filter value, and blocking combinations that would return zero results. Plus a URL that changes as filters are applied, so a filtered selection can be sent in a chat or used in an ad.
- Store numeric attributes as numbers, otherwise you can't offer a "from - to" range.
- Decide in advance which filters become their own pages for search, and which stay purely functional.
- Design the mobile filter view separately: on a phone it's a dedicated screen with a "Show N products" button, not a sidebar.
Product variants: where the most expensive rework waits
A variant (also called an SKU) is a specific combination: the same t-shirt, but blue and size L. A variant has its own stock level, barcode, sometimes its own price and its own photos. There's still one product page: the buyer picks colour and size without jumping between pages.
The alternative is creating every combination as a separate product. Sometimes that's justified, when the differences are substantial and the items sell independently. But in clothing and footwear it almost always ends with a catalogue ten times bigger than it needs to be, reviews scattered across clones, and three identical cards showing up under one colour filter.
This is exactly where the most painful rework happens. A store launches with a flat product list, six months later sizes get added, and it turns out you need to rewrite the product page, the cart, the sync with the inventory system, the marketplace feeds and all the analytics. That's why "will you have variants" gets asked before work starts, even if you don't need variants right now.
Decide separately what happens to an unavailable combination. Size L in blue has sold out - the variant should become inactive with a clear label, not quietly disappear and not let someone add something that doesn't exist to the cart.
- What distinguishes variants: colour, size, volume, configuration - the list gets fixed before development.
- What belongs to the variant: stock, price, photos, SKU code.
- What to do at zero stock: hide it, show it as unavailable, or offer a back-in-stock notification.
Stock levels and the source of truth
A catalogue only works in tandem with your inventory records. Answer one question: where does the truth about products and prices live - in the inventory system, in a spreadsheet, or on the site itself? If the truth sits in the inventory system, the site shouldn't let anyone edit those fields by hand. Two sources always drift apart, and a month later nobody knows which price is real.
From that follow the requirements for data exchange: what syncs (prices, stock, new products, photos), how often, and what happens when it fails. Agree separately on who owns content: descriptions, photos in a consistent format, filled-in attributes. A developer builds the catalogue mechanics, but no filter system can rescue five hundred product cards with empty attributes.
What to ask a developer before signing
The catalogue is the most expensive part of a store precisely because its price is set by data structure, not page count. A conversation about structure is a conversation about the quote.
If you ask for an itemised quote and get back a single number, that isn't a quote. The catalogue should be broken down: category tree, attributes and filters, variants, inventory sync, search, import.
- How many category levels, and where collections like "Bestsellers" and "Clearance" live.
- Whether filters are tied to categories or shared site-wide.
- Whether there will be product variants, and what belongs to them - price, photos, stock.
- What happens to a product at zero stock.
- What category URLs and filtered selection URLs look like.
- Who fills in attributes for the first batches of products, and in what format.
- What happens when the inventory sync fails, and whether anyone besides a customer will notice.
When none of this is needed
If you have twenty products with no variants, you don't need filters - they'd be filtering nothing, and it's easier to scroll the whole list. One page with a product grid and decent search is enough.
If there's only one product, or it's a service, you don't need an online store at all. A landing page with a form and payment solves it cheaper and faster, and you never have to think about stock levels and categories.
The reverse also holds: if you already have an inventory system, sizes and a few thousand items, don't try to save money on catalogue structure and make up for it with nice design. Design gets redone in weeks. Data structure takes months.
How we work on this
At EFIMOV DEV we don't start a store with mockups. We start with the catalogue model: category tree, attributes per category, the variant scheme and the inventory sync. We build on React and Node.js, and you'll discuss the work directly with the person running your project. Starting-from prices for online stores, support and other services are published on the site; the exact quote comes after the brief, once the product structure and data source are clear.
A catalogue starts with the data model, not the design: one category tree, attributes in their own fields, variants thought through, and a single source of truth for stock. Ask your developer to itemise those points in the quote - the answers show quickly who has built stores and who has only built pages.
Frequently asked
What's the difference between a filter and a subcategory?
A subcategory answers "what kind of product is this" and is filled manually. A filter selects products by an attribute within a category and works automatically. If you're about to create a "Blue t-shirts" subcategory, what you need is a colour filter, not a subcategory.
Can we launch a simple catalogue first and add filters and sizes later?
Launching a simple view is fine, and often sensible. But the data structure for variants and attributes has to be in place from the start, otherwise you'll later be rewriting the product page, the cart, the inventory sync and the analytics. Tell your developer about your plans early, even if you don't need variants yet.
How many products justify having filters?
Go by behaviour, not by count. Filters matter when a single category holds dozens of items and buyers choose by specific attributes - size, wattage, volume. With twenty products across the whole store, a grid and search are enough.
Who fills in product attributes?
Usually the client or their content manager, because it's product knowledge. The developer builds the mechanics, the value lists and the import from a spreadsheet or inventory system. Settle this before starting: empty attributes turn filters into dead weight.