E-commerce projects are sold on the storefront. The design is what stakeholders review, what gets presented, and what the timeline is built around. Then the project runs late, and the reason is almost never the storefront.
It is the catalogue. Specifically, it is the discovery that the product data which has been running the business quite adequately for a decade cannot be published to customers without a large amount of work nobody scoped.
Why internal data does not survive contact with customers
Product data inside a business is optimised for the people who already know what it means. A part number, a supplier code, a weight in whatever unit the warehouse uses, a description that says "as before but blue".
That works because the humans reading it have context. A customer has none, a search engine has none, and a filter has none. Publishing the catalogue means creating a second version of the truth aimed at people who do not work there - and that is a content project, not a data export.
The five questions that decide the timeline
- Where does a product actually live? Usually the answer is three places: an ERP with the commercial truth, a spreadsheet with the marketing copy, and someone's head with the exceptions. Establishing which system wins for which field is the single largest decision in the project.
- What identifies a product? Not "the SKU" - whether the SKU is stable, unique, and the same identifier the warehouse, the accountant and the supplier all use. Where it is not, everything downstream inherits the ambiguity.
- What is a variant, and what is a separate product? Colour and size are easy. Voltage, packaging quantity, region-specific certification and "the same thing but from a different supplier" are not, and every platform models this differently.
- Which attributes are structured? A dimension in a paragraph of description cannot be filtered on, compared, or used in a feed. Turning prose into fields is slow, manual and unavoidable, and it is where most of the hours go.
- What does a complete product look like? Write the definition down: images, structured attributes, description, price, stock, category. Then count how many products meet it today. That number, not the design, sets your launch date.
Images are their own project
Product photography is consistently underestimated because the business already has images - on a shared drive, at inconsistent sizes, some with backgrounds, some scanned from a supplier catalogue, many with no reliable link back to a product code.
Two questions settle it. Can every image be mapped to a product automatically, or does someone have to look at them? And do they meet a single standard - same background, same crop, same aspect ratio, high enough resolution to zoom?
If the answer to the first is "someone has to look", multiply your estimate by the number of products. That work is real, it is dull, and pretending it is not there does not make it go away.
B2B multiplies everything
If you sell to businesses, the catalogue is not one catalogue. Customer-specific pricing, contract-only products, minimum order quantities, unit-of-measure conversion, credit terms and the customer who has negotiated an exception to all of it.
None of that is a storefront feature. It is a data model, and it is the thing that decides whether a platform fits before anyone looks at a theme. Choosing on the storefront and discovering the pricing model afterwards is how B2B stores end up with a plugin holding the business together.
Who owns it afterwards
A catalogue is not a migration, it is an ongoing job. New products arrive, suppliers change specifications, prices move, images get replaced. If nobody owns that, the data quality you launched with is the best it will ever be.
Decide before launch: who adds a product, where they do it, which system is authoritative for each field, and what stops an incomplete product being published. The last one matters most - a validation rule that refuses to publish a product without images or a description does more for catalogue quality than any amount of cleanup afterwards.
How to sequence it
Start with the export, not the design. Get the real data out of the real system in week one and look at it.
Then model the products before choosing the platform, because the model is what platform choice should turn on. Then migrate a representative hundred products end to end - including the awkward ones people keep mentioning - before committing to the full set.
And launch with fewer, better products rather than everything at reduced quality. A partial catalogue that is complete and searchable outsells a full one nobody can filter, and it gives you a working definition of "done" for the rest.