Where this came from, and what it actually is
The origin is first-hand observation from a digital marketing strategy conversation, not desk research. A business owner supplying Italian tiles to architects has to specify 14–20 meta fields per product. Dimensions arrive in metres from one supplier and millimetres from another, sometimes within the same country. Surface finish is described inconsistently — polished versus not, plus supplier-specific finish names. Colours are given as marketing names such as "olive" rather than a canonical "green". Each supplier ships its own free-text product description.
The immediate trigger: a tile store on Shopify needed roughly 200 new products created, and the entire path from supplier documents to Shopify listings was manual data entry.
That is the whole of the validated pain. No third-party sizing, pricing, or willingness-to-pay evidence existed at the point the idea was written down, and the rest of this document is the attempt to find some.
The scope correction that changed the product
The idea owner corrected an early framing, and the correction matters more than it first appears. The output is not Shopify-specific. The goal is normalise-once, publish-many — the same unified product record publishing to Shopify, Magento, and WordPress/WooCommerce. Shopify was the example that surfaced the pain, not the target.
This changes the shape of the thing. It is no longer an importer that fills a Shopify store; it is a canonical product record plus per-platform publishing adapters, where each adapter owns that platform's schema quirks — Shopify variants and metafields, Magento attribute sets and attribute-set inheritance, WooCommerce product attributes and custom fields. The unified format becomes the actual asset, the thing a supplier owns and re-publishes from, and the storefront becomes a render target rather than the system of record.
Two consequences follow immediately, and both are unwelcome.
First, the buyer may change. Normalise-once/publish-many is most valuable to whoever runs multiple storefronts or is replatforming — an agency, a distributor with several brand sites, a supplier mid-migration — not necessarily the single-showroom owner originally described.
Second, the competitive framing hardens. Multi-channel publishing from a central record is the textbook definition of PIM plus syndication. That puts the idea head-on against Akeneo, Salsify, Sales Layer, Plytix, Productsup, Channable and Feedonomics rather than beside them. The wedge narrows to exactly one thing: the building-materials spec vocabulary and the supplier-format reconciliation that generic PIMs make you configure by hand.
Ingest is three source classes, so the record is a merge
The owner specified three ingest sources, and they are not variations of one pipeline. They carry different halves of the record.
Supplier website (crawl). Structured HTML spec tables plus images. Cheapest, needs no supplier cooperation, and uniquely enables continuous monitoring — re-crawl to catch new products, discontinued lines, spec revisions. Costs: terms of service, brittleness, politeness limits.
Inventory / ERP (Cin7 Core or Omni, Unleashed, DEAR, NetSuite). Clean and API-accessible, but carries commercial fields: SKU, barcode, cost, price, stock, supplier. Not the 14–20 architectural spec fields — nobody types slip rating or PEI class into an inventory system.
PDF / Excel (price lists, spec sheets, brochures). Messiest, highest extraction cost, but where spec data actually lives: thickness, finish, slip rating, frost resistance, rectified edge, application.
The consequence is structural: the canonical record is a merge, not an import. Commercial truth from inventory, spec truth from documents and website, joined on SKU or supplier code — which will not always match cleanly. Merge policy becomes first-class: per-field source-of-truth rules, conflict resolution when the ERP and the PDF disagree, and provenance on every field.