Do you need a PIM? Probably not, and here is the honest threshold
A PIM bought too early is shelfware with a licence fee. The threshold is channels times attributes times rate of change — and for most shops a spreadsheet is still the right answer.
Photo: free stock photography (Unsplash licence) — see imprint
Most PIM projects solve a problem the shop does not have yet
A PIM — Product Information Management — is a system whose entire job is to be the single place where product data lives, so that the shop, the marketplace, the print catalogue and the sales team's PDF all read from the same truth. It is a genuinely good idea. It is also, in a large share of the projects we get asked about, an answer to a question the business has not asked yet, sold on the strength of a demo where the data was already clean.
The failure mode is predictable and we have watched it more than once. A licence is signed, a data model workshop happens, everyone agrees the model is beautiful, and then somebody has to actually move 4.000 products with inconsistent attributes into it. Six months later the PIM holds a partial catalogue, the shop still gets its real data from the old export, and the product manager maintains both. That is not a PIM. That is a second place to be wrong, with a support contract.
The threshold: channels times attributes times rate of change
Product count is the number everyone quotes and it is close to irrelevant. A shop with 20.000 screws that never change, sold in one channel, with four attributes each, does not need a PIM — it needs a decent import. A shop with 300 machines sold through a shop, two marketplaces, a dealer portal and an annual print catalogue, each product carrying sixty attributes in three languages, and a product manager changing specs weekly, needs one badly. Same industry, opposite answers.
So multiply three things: how many places the data has to land, how rich each product record is, and how often it changes. One channel is a shop field. Two channels is an export script. Four channels with different required fields, different image formats and different category trees is a job — and it is a job somebody is currently doing by hand, badly, at eleven at night before a marketplace deadline. That person is your business case, not the licence brochure.
- One or two channels, stable data — a spreadsheet plus an import is correct.
- Three-plus channels with different required fields — start costing a PIM.
- More than one person editing the same product weekly — you have a locking problem.
- Two or more languages with real translation workflow — the spreadsheet is done.
The spreadsheet is not embarrassing. It is often correct.
There is a slight professional shame around admitting that a company runs its catalogue out of a spreadsheet. There should not be. A spreadsheet is fast, everybody already knows it, it costs nothing, it has revision history if you put it somewhere sensible, and it can be replaced on a Tuesday. Its weaknesses are real — no validation, no roles, no audit trail, no concurrent editing worth the name — but those weaknesses only start costing money at a certain scale.
Before you buy anything, do the cheap version of a PIM: agree one file as the source of truth, put required fields in it, add a column that says which channel a product is allowed on, and write an import that fails loudly when a required field is empty. That is perhaps a few days of work and it removes most of the pain that gets attributed to 'not having a PIM'. If it does not remove the pain, you now know precisely which pain remains — and that is the specification you should be shopping with.
What actually breaks when you buy one too early
The licence is the small number. The real costs are the data model you have to design before you understand your own catalogue, the migration of dirty historical data into a system that refuses dirty data, the integration to the shop and the ERP, and the process change — because a PIM only works if people stop editing product data anywhere else. That last one is not a technical project at all. It is a management decision that a piece of software cannot make for you.
Buy one when the pain is specific and nameable: 'our marketplace listings are three weeks behind the shop', 'we shipped the wrong dimensions to a dealer twice', 'the catalogue deadline costs us two weeks of one person every year'. Do not buy one because the catalogue feels messy. Messy catalogues get cleaned by people, not by software, and a PIM will simply store the mess with better search.
| Situation | Right tool | Why |
|---|---|---|
| 1 channel, stable attributes | The shop admin itself | A second system adds sync, not value |
| 2 channels, occasional change | Spreadsheet + validating import | Days of work, no licence, easy to leave |
| 3+ channels, differing required fields | Cost out a PIM seriously | Per-channel rules are what PIMs are for |
| Multi-language, several editors | PIM | Roles, workflow and audit trail stop being optional |
- Product count barely matters; channels times attributes times change rate is the threshold.
- A spreadsheet with required fields and a strict import solves most 'PIM' pain for days of work.
- A PIM bought before the pain is nameable becomes a second place to be wrong.
- The licence is the small number — data model, migration and process change are the bill.
Frequently asked questions
There is no product count that answers this, which is why the vendor question is always misleading. Twenty thousand unchanging screws in one channel need no PIM; three hundred machines across four channels with sixty attributes each and weekly spec changes need one. Count your channels, your attributes per product and how often they change — that product is your answer, not the row count.
As long as the shop is your only real channel, yes — custom fields and property groups cover a lot, and one system beats two. It stops working when other channels need product data the shop does not care about, or when the shop must not be the master because someone has to edit products before they are ready to be public. That is the moment the shop stops being a suitable home.
Take the licence and treat it as the smallest line. The budget goes into designing a data model, cleaning and migrating historical data, and building the integrations to shop and ERP — plus the unbudgeted part, which is teaching the organisation to stop maintaining products in five other places. If nobody owns that last change, the rest is money spent on a very tidy warehouse nobody delivers to.
Yes, up to a point, and there is no shame in it. One agreed file, defined required fields, a column for channel eligibility and an import that refuses incomplete rows removes most of what people call a PIM problem. Its real limits are concurrent editing, roles and translation workflow. When those three start costing you real hours every week, then go shopping — with a specification instead of a feeling.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer