Competitors and integration — the field-level evidence

The refutation that killed the original moat

This document's most load-bearing claim — "vision-enrichment vendors do not serve building materials; they target fashion, electronics and automotive" — was wrong in its strong form. Two statements withdrawn:

1. "Building materials are absent from these vendors' industries" — false.
2. "Its application to tile and lighting vocabulary is not evidently occupied" — too strong; partly occupied.

Worse, the confidence register had called this an unverifiable absence. It was verifiable, and verifying it broke it. It had been an inference from an absence of evidence — vendor pages listing fashion, electronics and automotive — not a positive finding.

And the counter-example was already half-visible in this page's own source index. SKU Launch is a product of Start with Data, a Melbourne company (+61 3 8376 1218). Its industry list names Building Supplies and DIY & Tools; it does AI document parsing of supplier PDFs and spec sheets. Named case studies: Huws Gray ("product data enrichment for a leading builders merchant"), MKM Building Supplies, Castorama, Kingfisher Group. The page had twice cited startwithdata.co.uk — including an article titled "the 5 best PIMs for builders merchants" — without connecting it.

The "unexplored Australian home turf" is already occupied by an Australian vendor selling to builders merchants.

PIM / syndication vendors with named building-products customers

• Syndigo at UFP Industries
• Sales Layer at BuildingMaterials.co.uk
• Bluestone PIM at Saint-Gobain Distribution Norway
• Pimberly — the acute threat. It ships ImageAI ("identifying materials, recognizing shapes or patterns") plus ColorAI, and its customers include Headlam, the UK's largest floorcoverings distributor. Both halves of the thesis, uncombined. If Pimberly joins them, the corpus lead is worthless.
• Also inriver, Salsify

Image-sourced attribute extraction already shipped

• Hypotenuse
• Velou
• Envive

The missed axis: visualisers, and they are the more dangerous set

• Renoworks — 200+ building-product manufacturer customers
• Floori — extracts UV and PBR maps from ordinary photos of tile samples
• Roomvo / Leap Tools — 250+ brands, 7,000+ dealers
• Consumer tile-ID apps already classify finish, look, pattern and size from a single photo — precisely the task this document called its moat

Warning sign: Lily AI ran a home vertical doing material and finish tagging in 2023. That page now 404s and the company lists only apparel and beauty. Someone tried this and retreated.

The three-moats verdict

• Moat 1 — building-materials taxonomy: GONE. ETIM is an open standard; ISO 13006 already standardises ceramic tile classification. A free public good.
• Moat 2 — AI extraction from messy supplier formats: GONE. Commodity, shipping in cheap Shopify apps (Shopif-AI, Importier, Apport) and mid-market SKU Launch. LLM improvement makes it cheaper every quarter, compressing margin.
• Moat 3 — multi-platform publishing: GONE. Cin7 Core documents Shopify, Magento and WooCommerce integrations; Cin7 Omni exposes editable field mappings; PIMs treat syndication as table stakes.

The squeeze: this sits in the valley between a cheap single-platform Shopify importer and a ~USD 30,000/yr enterprise PIM (Pimberly, Capterra, medium confidence). The buyer there — a showroom with a few thousand SKUs across twenty suppliers and two storefronts — is real but small, hard to reach, low willingness to pay. Both sides are expanding into it.

Honest read: as venture-scale software, weak. The differentiated work remaining is integration and mapping labour — a services shape, not a licence shape.

But one caveat in that verdict proved decisive: a Cin7 source noted that WooCommerce syncs stock automatically while descriptions and other product details need manual sync. "If shallow field coverage is typical, the enrichment gap is wider than this verdict assumes. Verify before killing." It was verified. It is wider.

The surviving positioning

Replace the "vision enrichment is shipped — but not here" framing entirely; it is refuted and cannot be softened into survival.

Honest restatement: the vertical is well served on the PIM/syndication axis (Syndigo, Sales Layer, Pimberly, Bluestone, inriver, Salsify, SKU Launch — all with named building-products customers) and well served on the visualiser axis (Renoworks, Floori, Roomvo, tile-ID apps). Nobody has joined them.

Across every vendor taxonomy checked, slip rating, PEI class, water absorption, frost resistance and rectified edge returned zero hits.

So the thesis is no longer "we infer where others cannot" but "we infer into the compliance-grade schema the specification channel needs, which merchandising-focused vendors have no reason to build." Consequences: the visualiser companies are the more dangerous competitor set, not the PIM vendors, and Pimberly is the acute threat.

Adjacent findings

• Vertical ERP / direct competitors exist in tile and flooring — a services-and-software tier already selling to this exact buyer.
• iPaaS / connector layer (previously missed) competes on the plumbing.
• Cin7's own integration directory: 700+ integrations, no PIM category, no PIM vendor. Nobody occupies the space.
• Matrixify correction — the one non-desk-research finding, from the owner's direct product knowledge.
• Supplier-confirmation pattern: SKU Launch replaces spreadsheet collection with a portal where suppliers confirm pre-filled data rather than typing (claims ~40% → 80%+ completion, vendor claim). Same confirm-not-type principle this document reached independently — evidence the pattern works, and that a competitor already applies it supplier-side.
• Akeneo CE feature freeze and EOL September 2026; running cost EUR 1,500–3,000/month (aggregator, medium confidence).

Cin7 Core → Shopify: the field-level evidence

17 fixed fields, enumerated from vendor docs: SKU, Name, Category, Description, Weight, Barcode, Price Tier, Images, Tags (first 256 chars only), Option 1/2/3, Variation, Brand, HS code, Country of origin.

Not carried:

• No Additional Attributes row at all
• No metafields — "metafield" returns zero results across the entire Cin7 Core help centre, verified via the Zendesk search API (count: 0)
• No dimensions — present in the Woo and BigCommerce mappings, absent for Shopify
• No unit of measure — fatal for tile, stocked by box and sold by m²
• No product attachments — no spec sheets, no DoPs, no slip certificates

The channel asymmetry is the crux: Core does carry its 10 additional attributes to WooCommerce and BigCommerce, but not to Shopify and not to Magento. An unbuilt integration, not an architectural limit.

Cin7 knows the data matters: Core's own B2B Portal has a "Show additional attributes" setting — it renders spec attributes on its own storefront with no pipe to push them to Shopify.

Correction to an earlier version of this document: the manual-sync limitation is not WooCommerce-specific. Cin7 Core's Shopify doc: "Product information must be manually updated to be exported to Shopify, it will never be updated automatically."

Core cannot be source of truth: max 10 attributes per set, ONE set per product, text capped at 256 chars, plan-gated — "Ignored when current Cin7 Core Subscription plan is Small or Medium." A tile spec sheet needs 20–40 fields.

Unleashed is narrower still: 9 fields; Tags and Vendor explicitly not synced; attribute values capped at 50 characters (unusable for spec prose); attribute sets appear nowhere in its Shopify mapping.

Cin7 Omni exposes an Update Recently Modified Products Field Mapping page mapping Omni fields to Shopify, with Omni data replacing Shopify data on upload. It has unbounded custom fields to 2048 characters and user-editable mappings — but metafields appear only as a blocking error. For WooCommerce, only stock availability syncs automatically.

The bigger-than-a-connector conclusion: because Core caps attributes so hard, this cannot be "read Cin7, write Shopify metafields". The enrichment layer must own its own datastore and use Cin7 only for SKU, stock and price identity — materially more product than a sync tool, which raises the bar on how strong the demand signal must be before building. And it has to be a global product with an AU beachhead.

Shopify platform mechanics

• Metaobject limits: 128 metaobject definitions per app, 30 fields per definition.
• Bulk Operations API: async GraphQL returning JSONL, tens of thousands of records without hitting standard rate limits; one bulk operation per type at a time per shop; mutations can partially fail, so retry logic is the builder's.
• Embedded vs standalone conversion: installed-to-first-use 70–85% embedded vs 45–60% standalone (aggregator, medium confidence).
• Shopify's own guidance names four cases where standalone beats embedded, and all four apply: UI needs more room than admin-chrome width; used by non-merchant roles (suppliers, agency staff, architects); spans multiple storefronts; is a full tool where Shopify is one integration among many.
• Shopify B2B gap: Shopify lacks native functionality for sales reps to take orders at trade shows or in the field — documented against purpose-built B2B wholesale platforms. The storefront may not be the centre of this customer's world.
• Unresolved: off-platform billing for connector apps where the vendor is a standalone SaaS acquiring zero merchants through Shopify — whether an exemption applies, or split billing. Flagged for whoever builds.

Ingest architecture: a merge, not an import

Three source classes:

1. Supplier website crawl — structured HTML spec tables plus images. Cheapest, needs no supplier cooperation, and uniquely enables continuous monitoring (re-crawl for new products, discontinued lines, spec revisions). Costs: ToS exposure, brittleness, politeness limits.
2. Inventory / ERP — Cin7 Core or Omni, Unleashed, DEAR, NetSuite. Clean and API-accessible, but carries commercial fields only (SKU, barcode, cost, price, stock, supplier). Nobody types slip rating or PEI class into an inventory system.
3. PDF / Excel — price lists, spec sheets, brochures. Messiest and dearest to extract, but where spec data actually lives (thickness, finish, slip rating, frost resistance, rectified edge, application).

The canonical record is a merge: per-field source-of-truth rules, conflict resolution when Cin7 and the PDF disagree, and provenance on every field.

PDF extraction: an architectural fork

• LlamaParse 8.54 seconds; Marker 47 seconds; Docling 1 minute 50 seconds (same test).
• Why: Docling runs one large vision-language model reading each page as an image, generating table structure token by token — inherently slow. Marker runs a 5-stage pipeline of smaller specialised models doing mostly classification and detection, avoiding token-by-token generation.
• Docling separately reported at 97.9% accuracy on complex table extraction. Unstructured has the strongest OCR.
• The constraint that decides it: LlamaParse is cloud-hosted on LlamaCloud, so documents leave your infrastructure. Supplier price lists carry confidential trade pricing. That disqualifies the fastest option and pushes the build to Marker or Docling running locally. An architectural fork, not a preference.

Open-source stack — build cost is assembly

• wbsg-uni-mannheim/ExtractGPT — LLM attribute value extraction
• wbsg-uni-mannheim/wdc-pave — extraction and normalization, the exact two-step needed
• google/langextract — structured extraction with precise source grounding, matching the provenance requirement
• Structured output: Instructor, Outlines, PydanticAI, Guidance
• Splink — probabilistic record linkage, a million records on a laptop in about a minute, 100M+ on Spark. Also Zingg, dedupe
• Papers: arxiv.org/pdf/2501.01237 (Self-Refinement for LLM-based Product Attribute Value Extraction), arxiv.org/html/2310.12537v4 (ExtractGPT)

Implication: build cost is assembly, not invention — cheap for us, equally cheap for anyone else. The corpus, not the pipeline, is the only asset.

Form factor: the review surface IS the product

It requires a durable record where every field carries extracted / derived / inferred / human-asserted status, corrections persist, and corrections accumulate into a labelled corpus. It is simultaneously the safety mechanism for the never-infer compliance rule and the collection mechanism for the corpus. Every human correction is a labelled example linking image + partial fields to a correct value.

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

• Office.js add-ins are web apps in a sandboxed iframe — deployable across Office on web, Windows, Mac and iPad, able to read/write worksheets and add task panes and custom functions — but strictly sandboxed and unable to access the local drive, so bulk ingestion of local supplier files from inside an add-in is constrained.
• A spreadsheet cannot carry per-field confidence, provenance or extracted/derived/inferred status, cannot support multi-user review, and does not persist corrections. Excel belongs as an import/export surface only.
• A Shopify app should still exist — as a distribution and publish channel, a thin client onto the standalone record, not the product.
• Review queue UI: image, source snippet, confidence and canonical value, side by side.

The demand hole

The weakest part of the whole dossier. Searched specifically: no forum threads, no reviews, no vendor complaints documenting anyone suffering from Cin7's inability to carry rich spec data to Shopify. The only signal is agency marketing copy.