Below about fifty items, a store is a design problem. Everything fits on two screens, browsing works, and a good layout carries the whole experience.
Past that, something changes that most owners never name: the customer stops experiencing your design and starts experiencing your data.
They type into a search box and get nothing. They filter by size and half the range vanishes because twelve products never had the attribute filled in. They find the same book listed three times because it exists in hardback, paperback and audio. They land on a page that says "in stock" for something the warehouse has not had for a month.
Not one of those is a design failure. Every one of them costs a sale, and none of them appear in your analytics as anything other than an exit.
The zero-results tax
Here is a number no store we have ever audited could produce on request: what percentage of internal searches return nothing?
It is trivially measurable — your search logs already have it — and it is one of the highest-signal figures in the business, because a search with no results is a customer who told you exactly what they wanted to buy, in their own words, and left.
Related, and equally unmeasured: how often does a customer search, get results, and click none of them? That is a relevance failure rather than a coverage failure, and it is usually worse, because it teaches the customer that your search does not work.
Together these form a tax that is paid entirely by people with purchase intent. Which leads to the uncomfortable second-order effect:
Bad search does not just lose sales. It changes what people buy. When search fails, customers fall back to browsing categories and sorting by price — because price is the one attribute that is always populated and always comparable. You have not merely lost conversions. You have quietly re-optimised your store toward your cheapest products.
That is a margin problem masquerading as a technical one.
Five measurements of catalog health
None of these need a platform. All of them need someone to care.
1. Null-result rate. Percentage of internal searches returning zero. Anything above 5% is a live wound. Read the actual queries — they are a free list of products you should stock and synonyms you should add.
2. Attribute completeness, weighted by revenue. Not "what percentage of fields are filled" but "what percentage of the fields on our top 100 revenue products are filled". A store can be 80% complete overall and 40% complete on everything that matters.
3. Duplicate and variant collapse. Does one real-world thing appear as one entry, with its formats and editions underneath? If the same item appears three times, you are splitting its reviews, its ratings, its search relevance and its stock across three weaker records.
4. Freshness lag. How long between reality changing — a price, a stock level, a discontinuation — and your storefront saying so. Measure it in hours, and measure the worst case, not the average.
5. Synonym coverage. Take the twenty phrases customers actually use, including misspellings and the other language they might use, and search your own store for each. Count the failures.
What a correct data model looks like
An example, because this is where the abstraction stops being useful.
Knigopoisk is a Russian-language store with a catalogue advertising more than 11,000 books. The original model treated each saleable item as a product. That works until one work exists as an e-book, a paperback and an audiobook — at which point the same title is three unrelated records with three sets of reviews, three ratings and three chances to be the one the customer never finds.
In 2026 we restructured it into a Book → Edition → Product model through phased migrations: a new data layer with backfill, an ownership cutover, a public API re-sourced over products, and finally a new catalogue console in the admin. One work can now carry several editions and formats without duplicated records.
Two things about that are worth extracting.
It was done in phases, not a big bang. A catalogue restructure on a live store is the highest-risk change you can make. Each phase shipped independently and could be stopped.
The admin console was the last step, not the first. The instinct is to redesign the screens. The screens are the consequence of the model; changing them first just makes the wrong model easier to type into.
Three data models, and how to know which one you need
Nearly every catalogue problem traces back to picking the wrong one of these at the start, when it was free to choose and nobody was paying attention.
Model A — flat items. One row per thing you sell. Correct when every item is genuinely distinct: art, antiques, services with no configuration, one-off inventory. Breaks the moment the same thing exists in two sizes.
Model B — product with variants. One product, many purchasable variants along defined axes (size, colour, capacity). Correct for most retail. The discipline it demands is that the axes are declared — "size" is a dimension with known values, not free text typed per product. Breaks the moment the same work exists in formats that are not variants of each other but different things entirely — a hardback and an audiobook are not two sizes of one object.
Model C — work, edition, product. An abstract work; editions of it; purchasable products under each edition. Correct for books, music, film, courses, software licences, anything with translations, formats or regional versions. Costs more up front and is close to impossible to retrofit once reviews, ratings and orders have attached themselves to the wrong level.
The test that decides it in one question: if a customer reviews this, what are they reviewing? If they are reviewing the story rather than the paperback, you need Model C, because the review belongs to the work and must be visible on every edition of it. Get that wrong and you split your own social proof across three listings — which is exactly the problem Knigopoisk's restructure existed to fix.
One more rule, learned expensively and applicable to all three: never let a display concern into the model. "Featured", "homepage banner", "sale badge" are presentation states, not product attributes. The day they live on the product record is the day your catalogue starts encoding last year's marketing campaign, and nobody will ever dare delete them.
The part where the data comes from outside
If your catalogue is fed by suppliers, feeds or APIs, the problem compounds — now you are not just maintaining data, you are reconciling disagreements between sources.
Finkonkurs is an extreme version: a market data platform whose scraper layer runs more than 120 scraper classes across over 40 providers, from market data APIs to exchange announcement pages. The architectural decision that makes it tractable is simple and it generalises:
Everything lands in one raw table first, with SHA-256 deduplication and schema fingerprinting, before anything is allowed to become a fact on a page. Transformation into domain models happens afterwards, through more than 50 dedicated transformer classes, reading from a read-only view.
The rule behind it: never let an external source write directly into the thing your storefront reads. Raw in, transform, then publish. When a supplier changes their format at 3am, the fingerprint catches it and the pipeline fails loudly instead of silently corrupting your prices.
The same reasoning drives a rule on our AI content pipeline for the same platform: a run that returns rate-limited, unfunded or empty fails with a reason instead of publishing a stub over an existing description. And volatile values like a coin's rank or an exchange's fee are kept out of the generated prose entirely, held as [[ placeholder ]] tokens the backend renders from live data at page-view time. Generated text goes stale. Rendered data does not.
Search is infrastructure, not a feature
One more architectural note, because it determines what is possible later.
On Bronjoy — 23,727 venues as of September 2026 — search runs on Meilisearch rather than database queries, and it matches across both Latin and Cyrillic, because a customer in Uzbekistan may type the same business name either way. Directory vocabulary such as services, amenities and payment methods is translated once into a shared dictionary and resolved per request, rather than being stored per venue. And venues keep a slug history, so a renamed business's old URL still resolves to its current page.
Each of those is a decision that would be nearly impossible to retrofit and nearly free to build in. That is the general shape of catalogue work: the expensive decisions are the early ones, and they are all about the model rather than the interface.
What this means for your next project
If you are planning a redesign and your catalogue has real size, the honest sequencing is:
- Fix the model — one thing, one record, variants underneath
- Fix completeness on the products that make the money
- Fix search — coverage, synonyms, and the null-result rate
- Fix freshness — how fast reality reaches the page
- Then redesign
Doing it in the other order produces a beautiful store that still cannot find its own products, which is the most common expensive outcome in e-commerce.
It is also now the prerequisite for the next channel: an AI shopping agent reads your attributes, your availability and your totals, and nothing else. We cover that in when the buyer is a program.
Our e-commerce builds start with the commerce model — products, variants, pricing, shipping and tax rules mapped before anything is designed — from $499 with a 1–5 week delivery. For catalogues that have outgrown a storefront platform entirely, that work usually belongs in custom web apps instead, and we will say so.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
How big does a catalogue have to be before this matters?
Roughly when a customer can no longer see everything you sell in two minutes of scrolling. In practice that is somewhere between fifty and a few hundred items, earlier if your products have variants.
Can I fix search without touching the data?
Partially. A better search engine handles typos, stemming and synonyms, which recovers a meaningful share of null results. It cannot invent an attribute nobody filled in, and it cannot merge three duplicate records into one. Tooling raises the ceiling; data sets it.
Is a headless architecture necessary for this?
Not necessary, but it helps for a specific reason: it separates the catalogue from its presentation, so the same data can feed a storefront, an app, a partner widget and an agent interface without being restructured each time. That flexibility is the actual argument for headless, not speed.
Who should own the catalogue internally?
One named person, with authority to reject bad supplier data. Catalogues degrade when ownership is split between merchandising, operations and IT, because every one of them assumes someone else is checking completeness.
What is the cheapest first improvement?
Turn on search logging if it is off, then read a week of queries that returned nothing. It costs an afternoon, it needs no development, and it will produce a list of specific fixes worth more than most redesigns.
