The starting point
An industrial distributor was bringing its catalog to Shopify. That catalog held more than 5,000 technical SKUs, and each one carried the information industrial buyers actually rely on: specifications, downloadable files, technical documentation and product imagery. The customers were businesses, and businesses expect to see their own pricing and availability, not a public price list. The existing site had URLs with organic visibility worth protecting, and an ERP integration covering products, pricing and inventory was planned for the future.
None of that is unusual on its own. The risk is in the combination. A technical catalog of this size rarely fails on launch day. It fails later, when filters stop making sense, imports break because products were built slightly differently from one another, and the integration work reveals that the data model cannot hold what the business system needs to send it.
So the job was not to “build a store.” It was to design the structure everything else sits on. I do not advise growth. I build it, and on a project like this, building it starts with the foundation.
What I did
Product architecture and templates
I started with the product model, because every later decision depends on it. With more than 5,000 SKUs, the question is not how one product page looks. It is how products, variants and their attributes relate to each other, so the same logic holds for the first product and the last, and the catalog stays consistent as it grows.
Then the templates. I standardized product templates so that specifications, downloads, technical documentation and imagery appear in the same place and the same format on every product. For a technical buyer, that consistency is the experience. For whoever maintains the catalog, it turns a new product into a data task instead of a design task.
Metafields and taxonomy
Technical products live or die on their attributes. I introduced metafields and a taxonomy so that specifications are stored as structured data rather than buried in description text. That does two jobs. It makes scalable filtering possible, because filters only work on data that is structured and consistent. And it prepares the catalog for future bulk imports, because an import can only map cleanly onto fields that already exist and mean the same thing across every product.
B2B customer structure
Industrial buyers do not shop like consumers. I designed the customer structure around account-specific pricing and availability, so each business account sees the terms that apply to it. Getting this right early matters. Pricing logic touches the catalog, the customer records and every system that will later feed them, and retrofitting it after launch costs far more than designing for it up front.
SEO migration and ERP readiness
A replatform is one of the fastest ways to lose organic visibility. I mapped the existing URLs into an SEO migration and redirect framework, so old addresses lead to their correct new destinations instead of dead ends. The aim was simple: protect the visibility the business had already earned.
Finally, I prepared the architecture for future ERP integration covering products, pricing and inventory. The integration itself comes later, but the product fields, the pricing structure and the data model were designed with it in mind. The intent is that when that stage arrives, connecting the ERP is a mapping exercise, not a rebuild.
Results
This was a foundation project, so the outcomes are structural. There are no before-and-after figures to put in a table, so I report the outcomes as delivered rather than dress them up with numbers the work was not designed to produce.
- Product architecture designed for a catalog of more than 5,000 technical SKUs
- Product templates standardized for specifications, downloads, technical documentation and imagery
- Metafields and taxonomy introduced to support scalable filtering and future bulk imports
- B2B customer structure designed around account-specific pricing and availability
- Existing URLs mapped into an SEO migration and redirect framework to protect organic visibility
- Architecture prepared for future ERP integration covering products, pricing and inventory
What made the difference
Structure before storefront. The product model, templates and metafields were treated as the core of the project, not as details to sort out after the design. Design can change in an afternoon. A broken data model follows you for years.
Designing for the next stage, not just launch. Bulk imports and ERP integration were not part of day one, but the catalog was built as if they were.
B2B as architecture, not an add-on. Account-specific pricing and availability shaped the customer structure from the start instead of being bolted on later as a workaround.
SEO inside the migration, not after it. URL mapping and redirects were part of the plan, not a cleanup task once traffic had already dropped.
If your catalog is heading to Shopify and it is more complex than a standard store, see how I approach Shopify development.