On 2026-09-18 openProd.io was selected for Road to Slush, the first edition of the Investor Ready track run by Gdansk Bay Tech and the Gdansk Entrepreneurship Foundation. Six Pomeranian teams were picked from the intake. The mission goes to Helsinki on 2026-11-17, the conference itself runs 18 and 19 November, and the preparation track starts weeks earlier with workshops, individual consultations and an Access Day checkpoint on 2026-10-29.
That is the announcement, and it is the least interesting part of this post.
The interesting part is what we intend to argue about once we are there, in a hall with roughly 12,000 attendees and 3,300 investors, most of whom will spend those two days talking about AI agents.
They are right about agentic commerce. They are too polite about where it breaks
The thesis on every stage this autumn is that commerce is becoming agentic. Shopify turned the catalog into a protocol. ChatGPT started serving feed-based sponsored products. Every major PIM vendor shipped an MCP server within the same two quarters. All of that is correct, and none of it is marketing fiction.
What the same rooms say more quietly, if at all, is which layer actually decides the outcome. An agent does not judge your checkout UX. It judges the attributes behind the product, and those attributes arrive from suppliers as PDFs, spreadsheets, XML exports and scans, in a dozen languages and several dozen unit conventions.
MCP is a port. It exposes whatever cargo you already have. If the cargo arrived as a 400-page supplier catalogue that a junior analyst is retyping into a spreadsheet, the protocol changes nothing about what the agent sees.
That gap between what suppliers send and what a PIM will accept is the intake layer. No PIM owns it, because no PIM was built to do it. This step comes before the PIM, and implementations stall here: platform live, model configured, supplier catalogue still outside it in week six.
What 70+ implementations say about the size of the step
LemonMind, the agency that built openProd, has delivered more than 70 PIM and e-commerce implementations over 15 years, with volumes up to 10 million SKUs. Those projects are the dataset behind the numbers below: measured work, not a market estimate.
| Task | Manual | With openProd |
|---|---|---|
| 1,000 products to PIM-ready | about 3 months, about EUR 14,000 | hours |
| One supplier PDF to PIM-ready | days of cleanup | about 15 minutes on a live file |
| 4,000 products processed | weeks | about 1.5 minutes |
| Variant recognition from one catalogue | manual reading | 128 variants detected from a single PDF |
The detail that matters most to anyone who has run this in production is not the speed. Every extracted field carries a confidence score. The system proposes, a person decides, and review time goes where the model is unsure instead of being spread evenly across the whole catalogue. Automation that removes the check does not reduce cost, it moves the cost downstream into corrections.
For the full cost breakdown behind the EUR 14,000 figure, see The EUR 14K Question.
The CFO version of the same argument
Strip the AI language out and this is a unit cost question.
A distributor onboarding 20,000 SKUs a year at roughly EUR 14 per SKU of manual preparation is carrying about EUR 280,000 of annual effort that appears in no budget line called onboarding. The effort sits in headcount across purchasing, marketing, IT and whoever was available that quarter. That dispersion is why it rarely gets measured, and why it rarely gets fixed.
The relevant questions for a finance owner are narrow:
- What does 1,000 SKUs cost to onboard today, measured, not assumed?
- How many weeks of a platform project go on waiting for supplier data instead of configuring the platform?
- What does a delayed catalogue cost in launches that slipped to the next quarter?
When those three numbers exist, the payback conversation takes minutes, because the comparison is against work already being paid for.
Why this belongs at an investor conference, not only at a PIM conference
We have argued this thesis in the rooms where it is easy. A full masterclass at Pimcore Inspire 2026. A keynote at GRID#26, Poland’s first product data conference. A Top 10 finalist place at the Pomeranian Startup Contest during Infoshare. In each of those rooms the audience already lives with supplier files, so the problem needs no introduction.
Helsinki is a harder room, and that is the point. Investors and operators there are not paid to care about BMEcat, ETIM or classification stores with 600 attributes. They are paid to recognise durable infrastructure early. So the question we are taking to Slush is whether the intake layer reads as infrastructure to people who have never opened a supplier PDF, or whether it only reads that way to those who have.
We think it does, for a structural reason. Standards keep improving and suppliers keep ignoring them, as BMEcat 5.0 and ETIM xChange show in detail. Every new distribution surface, from marketplaces to AI agents, raises the quality bar on the same upstream data. The layer that gets supplier files into a usable state is therefore not a bridge technology waiting for PIMs to absorb it. Every other part of the stack depends on it, and none of them owns it.
What we want out of Helsinki
Concretely, three things, and we would rather say them in public than discover them in a debrief.
First, meetings with teams running multi-supplier catalogues in the Nordics and DACH, where we can put a real file through the system instead of showing slides. Second, conversations with PIM and commerce integrators, because openProd is PIM-agnostic by design and integrators are how the layer reaches catalogues we will never sell to directly. Third, investor conversations that pressure-test the category framing, not the demo, since the demo has been tested and the framing is the harder question.
If you are going to Slush and product data is somewhere in your operation, bring the worst file a supplier sent you this year. Fifteen minutes and a live file settle the argument faster than any deck.
What is your cost per 1,000 SKUs onboarded, and who in your organisation currently owns that number?
