Why we built LinkXG

I was sitting with the operations team at a packaging company when they received their third product data request that week. A cosmetics brand needed material composition, recyclability credentials, and emissions data for a range of products. The team knew exactly where the data was. They had compiled it two weeks earlier for a different customer. But that customer had wanted it structured differently, against a different reporting framework. So they pulled up the old spreadsheet and started reshaping it: moving columns, stripping out fields that did not apply, adding others that did. It was the same underlying data, reorganised for a different audience in a different structure.

Meanwhile, they were waiting on their own suppliers to respond to requests they had sent ten days ago. It was the same problem in the opposite direction. The whole room understood this. Nobody talked about it as something to solve. It was simply the way things worked.

I remember looking at the spreadsheet they were working from and realising it was already a third-generation copy. The original had been built for one customer, reshaped for a second, and was now being reshaped again. Somewhere along the way, a few rows had been duplicated. A column that mattered for the first customer had been stripped out but was needed again now. The data had not been lost, exactly. It had fragmented. Each version was a little less reliable than the last, and nobody had time to go back to the source and rebuild. These were companies operating on thin margins, absorbing an endless records management burden that never produced a clean, reusable result.

The same pattern, repeated across every supply chain

That company was not unusual. The pattern repeated everywhere we looked, across chemicals distribution, materials manufacturing, and retail supply chains.

A mid-chain chemicals distributor spends its week reformatting material composition, source-of-materials, and regulatory compliance data for different customers. Each customer has a different template. Each request arrives as though the previous one never happened. The data is the same. The format never is.

A major retailer with thousands of suppliers has no system for collecting product-level data from its supply chain. The current process is email, spreadsheets, and individual requests sent one at a time. There is no consistent format, no central repository, no audit trail. When someone internal asks how product data is collected and verified across the supplier base, there is no defensible answer.

The effort does not scale linearly. A company serving two customers with overlapping data needs does not do the work twice. It does the work differently twice, because the formats, the frameworks, and the reporting structures are never aligned. Add a third customer, and the work multiplies again.

And then the data goes stale. A supplier sends product composition data by email. Three months later, the composition changes. The customer is still referencing the old version. Neither party knows, because there is no mechanism for the update to propagate.

This pattern sits at the centre of every supply chain, but it is most acute for mid-chain companies: the distributors, converters, and component manufacturers who sit between raw material suppliers and the brands that sell to consumers. They absorb data requests from customers above them and chase data from suppliers below them. They are the point where every inefficiency concentrates.

The problem is structural, not procedural

The more carefully we examined this, the clearer the core issue became. It is not that the data does not exist. Companies generate it, maintain it, and understand it well. The problem is that there is no infrastructure for sharing it. Every exchange is a point-to-point transaction, and each transaction either starts from scratch or mutates the last version into something slightly less reliable. The data degrades as it travels. The effort never accumulates into something a company can build on.

We spent a long time with this problem before we wrote a line of code.

What became clear was that the problem is structural, not procedural. No amount of process improvement addresses it. Better templates do not address it. Faster email does not address it. Another customer portal that asks suppliers to enter the same data into yet another form does not address it. These responses accept the architecture of the problem and try to operate more efficiently within it. The architecture itself is the issue. This is why the same companies that have invested heavily in enterprise resource planning (ERP) systems, compliance platforms, and internal data management still spend their weeks on email and spreadsheets when it comes to sharing data with trading partners. The internal systems are sophisticated. The space between companies is not.

Why supply chain data sharing needs infrastructure

Every new portal, every new customer template, every new data collection exercise adds another bilateral connection to an already tangled web. The web gets more complex. The work gets heavier. But nothing accumulates into something a company can build on.

What the problem requires is infrastructure: a system that treats the data source as the authority, allows companies to share information with their partners without duplicating it, reformatting it, or losing control of it, and makes every new trading relationship easier than the last rather than starting the same work from the beginning.

The conviction arrived quietly: this infrastructure should exist, and nobody was building it. So we decided to build it.

How LinkXG approaches product data sharing

LinkXG is a sharing network for product and company data across supply chains. Every design decision is a direct response to something we observed in the problem.

The network model exists because the matrix problem demanded it. In most current approaches, a buyer builds a portal and asks its suppliers to populate it. That creates bilateral connections: one buyer, many suppliers, one direction. A supplier serving five customers populates five portals with largely identical information. LinkXG works differently. A company uploads its product data and company credentials once, to one place, and shares from there with every partner who needs access. The effort invested in structuring and maintaining the data pays off with every subsequent connection, not just the one that prompted it.

The source-of-truth architecture exists because of the stale data problem. LinkXG does not copy, aggregate, or reinterpret data. The company that owns the data maintains it. When they update it, every partner with access sees the current version. There is no lag, no version confusion, no email trail to reconcile. The data is always as current as the source, because the source is the data.

Granular access control exists because sharing should not require surrendering control. A company decides exactly what each partner can see, down to individual products and individual data fields. A customer who needs material composition data does not automatically see pricing, supplier relationships, or full product specifications. Permissions are immediate to change, and every access is logged. The audit trail is not an afterthought. It is a consequence of the architecture.

We made the supplier tier free. This was not a pricing tactic. It was an architecture decision. If the companies that generate and maintain the most granular product data face a cost barrier to participating, the network cannot grow. Their presence is what makes the network valuable for buyers and mid-chain companies alike, and the infrastructure should reflect that.

The result is a platform where a company maintains its data once, as the authoritative source, and shares it with partners as simply as granting a permission. New customer relationships become a configuration step, not a data entry exercise.

What this means for product data across supply chains

The regulatory landscape is arriving at the same conclusions. Across Europe and beyond, incoming frameworks for product transparency, supply chain due diligence, and sustainability reporting all converge on a shared set of requirements: that the data is traceable to its source, that it is current, and that it can be audited. That convergence confirms the direction. But the direction was set by the problem, not by regulation. The infrastructure is worth building because the work companies do every day to share product data across their supply chains deserves to produce something lasting, not to degrade with every iteration.

We are at the beginning, building carefully, because this infrastructure deserves to be built properly rather than quickly. If that description matches a problem you recognise, we would welcome the conversation.