The question of a built-in or separate PIM system for ecommerce comes up in almost every platform evaluation: is a built-in PIM enough, or do you need a dedicated system such as Akeneo or inRiver? The answer is rarely decided by feature lists. It is decided by what your catalogue looks like, how many channels you publish to and who in the organisation actually owns the product data.
Here is a straightforward run-through of what a PIM does, where the line between built-in and separate sits in practice – and a decision checklist you can use directly in your evaluation.
What a PIM does – and what it does not do
PIM stands for Product Information Management: a structured home for all enriched product information. Copy, attributes, relations, images, documents, translations and channel-specific variants. The point is that product data is created and quality-assured in one place and then published to many – webshop, marketplaces, reseller portals, printed price lists.
Just as important is what a PIM is not. It is not stock levels, prices or order logic – those live in the ERP and the ecommerce platform. A common setup is that the ERP owns item numbers and base data, the PIM owns the enrichment and the ecommerce platform owns the presentation. Ambiguity in that chain creates more problems than any system choice.
The symptoms that the PIM question needs an answer
The need usually shows itself long before anyone says the word PIM. Product copy lives in scattered spreadsheets, the same attribute has different names in different categories, translations lag behind, and nobody knows which image is the latest. If relaunching a product requires three people emailing files to each other, that is not a discipline problem – it is the absence of a structured home for the product data. The only question is whether that home should be part of the ecommerce platform or a system of its own.
When is a built-in PIM system enough for ecommerce?
HDL Commerce ships with a built-in PIM, and for many Nordic merchants it goes all the way. A built-in PIM is the right choice when:
- Ecommerce is the main channel. Product data is consumed primarily by your own store, not by a dozen external channels.
- A small team owns the data. The same people who work with the assortment and content enrich the products – then one system fewer is a win, not a limitation.
- Enrichment happens close to sales. Categories, attributes and product copy are tightly coupled to how the store is built and how customers search.
- You want to avoid double licences and double integrations. A separate PIM is not just a licence cost – it is also one more integration to build, monitor and maintain.
The main advantage of a built-in PIM is that there is no synchronisation to wait for or troubleshoot between the product data and the store. Attributes, filters and variants are the same thing in the PIM as in the checkout flow. How the built-in PIM fits into the rest of the core is described on the platform page.
When a separate PIM is justified
There are situations where a dedicated PIM such as Akeneo or inRiver earns its place in the architecture. If you recognise yourself in several of the points below, you should evaluate a separate system seriously:
- Many channels with different requirements. Your own store, marketplaces, resellers and print – where every channel needs its own variants of the same product data.
- Large and complex catalogues. Tens of thousands of items with deep attribute models, supplier data that needs cleansing and rule-driven quality gates before publishing.
- Several companies or brands share the catalogue. The same base data should be enriched once and used across multiple stores and organisations.
- A dedicated product data organisation. If there are roles whose entire job is product information – with workflows, approvals and completeness scores – a dedicated tool is built for exactly that.
If you go that route, it matters that the ecommerce platform has ready-made connections instead of a custom build. HDL Commerce has connectors for both Akeneo PIM and inRiver among its 200+ ready-made connectors – see the integrations overview. A separate PIM does not rule out the platform; it only changes where the enrichment happens.
The decision in practice: five questions
Strip away the feature comparisons and ask these questions internally. They tend to settle the choice faster than any demo:
- How many channels do we publish to today – and in two years? One channel points to built-in. Five dissimilar channels point to separate.
- Who enriches the products? The same team that runs the store: built-in. A dedicated product data organisation with workflows: separate.
- What does the supplier data look like? Does it arrive structured and mostly needs completing, or does it require cleansing, mapping and rule sets at scale?
- What does the whole cost? Count licence plus integration plus maintenance for the separate option – not just the licence.
- What is reversible? Starting with a built-in PIM and adding Akeneo or inRiver later is a far smaller operation than going the other way.
A common middle ground
Many B2B merchants land in a middle ground: the ERP remains master for items and prices, the built-in PIM is used for enrichment and the channel is their own store. Only when a second or third major channel arrives is the question revisited. That is a perfectly sound strategy – it defers the cost until the need is proven, instead of building for a scenario that may never occur. Examples of how different businesses have put their setups together can be found among our solutions.
Whichever route you choose: make sure the product data is accessible through open interfaces. HDL Commerce exposes product data via REST & GraphQL APIs, which means a future PIM switch or channel addition does not require redoing the foundation. The details are on the developer pages.
And remember that moving the product data itself is a work package of its own, whichever route you take. When you switch platforms, a free migration analysis is included, where the state of the product information – attributes, images, relations, translations – is mapped before the project starts. That exercise usually answers by itself how big the PIM need really is.
Not sure where you land? Take it to a demo
Tell us what your catalogue, channels and organisation look like, and we will show you how the built-in PIM handles your specific products – and tell you honestly if we think you should look at a separate PIM instead. Book a walkthrough here.
