The review surface is the product

An early competitor entry overstated Matrixify. From direct product knowledge: Matrixify provides no user interface into the data. Its configuration is over CSV/Excel only. It is a bulk import/export engine, not a place where product data lives and can be inspected or corrected.

Why that is structural rather than a missing feature: the surviving thesis is inference — filling fields the supplier never sent, some derived by rule and some inferred from imagery. An inferred value is epistemically different from an extracted one. It needs a confidence score, a source pointer, and a human confirm or reject before it is safe to publish. A CSV round-trip cannot express "this colour family was inferred from the product image at moderate confidence, click to confirm". The moment the artefact is a spreadsheet, provenance and confidence collapse into flat cell values and the review step becomes unauditable.

So file-based tools are not merely behind on UI — they are architecturally excluded from the inference product.

Without overclaiming: some app-tier competitors do have review surfaces. Importier generates descriptions and then lets you review everything in a bulk editor. The honest distinction is not "UI versus no UI" but persistent canonical record versus import batch. A bulk editor reviews one import into one platform and is then discarded. The inference thesis requires a durable record where every field carries extracted / derived / inferred / human-asserted status, where corrections persist, and where those corrections accumulate.

The consequence for positioning: the review interface is not a nice-to-have layered on the pipeline. It is the product surface, because it is simultaneously the safety mechanism for the never-infer compliance rule and the collection mechanism for the corpus.

And that corpus is the one asset that compounds. Every human correction in the review queue is a labelled example linking an image plus partial fields to a correct value, in a vertical the enrichment vendors serve fashion instead of. The taxonomy is public and extraction is commodity; this corpus is neither.

Form factor follows from that

A standalone web app at the core, thin connectors at the edges. Not a Shopify app, not an Excel plug-in.

Shopify's own guidance names four cases where standalone beats embedded, and all four apply here: the UI needs more real estate than admin-chrome width (the review queue puts image, source snippet, confidence and canonical value side by side); it is used by non-merchant roles (suppliers confirming data, agency staff, architects); it spans multiple storefronts; and it is a full tool where Shopify is one integration among many.

The cost is known and should be accepted knowingly: installed-to-first-use runs 70–85% embedded versus 45–60% standalone. So a Shopify app should still exist — as a distribution and publish channel, a thin client onto the standalone record, not as the product.

Excel is the wrong home but the right doorway. Office.js add-ins are web apps in a sandboxed iframe across web, Windows, Mac and iPad, so it is technically viable — but a spreadsheet cannot carry per-field confidence, provenance or extracted/derived/inferred status, cannot support multi-user review, and does not persist corrections. That is the same structural disqualification established for Matrixify. Add-ins are also strictly sandboxed by the browser engine and cannot access the local drive, so bulk ingestion of local supplier files from inside an add-in is constrained. Excel and Sheets belong as import/export surfaces only.

On the publish path, Shopify's Bulk Operations API is the right mechanism: async GraphQL returning JSONL, handling tens of thousands of records without hitting standard rate limits. Caveats: one bulk operation per type runs at a time per shop, mutations can partially fail so retry logic is yours, and there are limits of 128 metaobject definitions per app with 30 fields per definition.

There is also an unresolved commercial question. A Shopify developer-community thread covers off-platform billing for connector apps where the vendor is a standalone SaaS acquiring zero merchants through Shopify, and whether an exemption applies versus split billing. If the Shopify app is only a publish channel onto a standalone product — the recommended architecture — billing needs deliberate handling and is not automatic.

Build shape: assembly, not invention

Nearly every component already exists as open source, which cuts both ways.

Taxonomy, the big one. The ETIM Classification Model is published under the Open Data Commons Attribution Licence, free for everyone, with downloadable full-model files plus a Swagger-documented REST API using OAuth2. As established above, bSDD serves the same content with no authentication at all. The canonical schema is not merely public — it is programmatically consumable today at zero licence cost.

PIM backbone. Pimcore is open source and self-hostable, spanning PIM, DAM and MDM, and one comparison scores it 35/40 across eight PIM capabilities against Akeneo's 31/40, leading on data modelling, governance, digital asset linkage, localisation and interoperability. Critically, Akeneo Community Edition has had no new features since 2023 — last major CE release v7 in March 2023, support only to September 2026, with development moved to paid editions. That is a live gap. Alternatives: AtroPIM, UnoPIM, PixeePIM.

The economics are not free, though. Akeneo CE is free to licence but budget EUR 15,000–40,000 for initial setup via a partner, with an operational instance at EUR 1,500–3,000 per month all-in (server, maintenance, plugins), excluding in-house developer time. Pimcore commercial deployments start at Professional, USD 9,900/yr; Pimcore Community has no cloud-hosted option, so you self-host and need a PHP/Symfony developer to configure the server and build connector logic per channel. And a material omission now corrected: Akeneo leads on supplier onboarding, via its Supplier Data Manager — directly adjacent to this idea's ingest half, and missed in the first competitor scan.

Document extraction, with a precise benchmark on the same test: LlamaParse 8.54 seconds, Marker 47 seconds, Docling 1 minute 50. The architectural reason matters — Docling runs one large vision-language model reading each page as an image and generating table structure token by token, which is inherently slow, while Marker runs a five-stage pipeline of smaller specialised models doing mostly classification and detection, avoiding token-by-token generation. Docling was separately reported at 97.9% accuracy on complex table extraction. Unstructured has the strongest OCR.

There is a constraint here that forks the architecture rather than expressing a preference: LlamaParse is cloud-hosted on LlamaCloud, so documents leave your infrastructure. Supplier price lists routinely carry confidential trade pricing, which disqualifies the fastest option and pushes the build toward Marker or Docling running locally.

Attribute extraction, directly on point. wbsg-uni-mannheim/ExtractGPT covers LLM attribute value extraction; wbsg-uni-mannheim/wdc-pave covers extraction and normalisation — the exact two-step needed. google/langextract does structured extraction with precise source grounding, which is this idea's provenance requirement. For structured output: Instructor, Outlines, PydanticAI, Guidance.

Deduplication. Splink does probabilistic record linkage — a million records on a laptop in about a minute, 100M+ on Spark. Also Zingg and dedupe.

The implication is uncomfortable: build cost is assembly, not invention — cheap for us, and equally cheap for anyone else. That reinforces the conclusion that the correction corpus, not the pipeline, is the only asset that compounds.

One more scope note on the standard: products outside electrical, HVAC, plumbing and building materials — consumer electronics, food, fashion, industrial machinery — have limited or no ETIM coverage. ETIM is the right standard for this vertical and would not generalise if the idea expanded beyond building products.