The default recommendation is a PIM and a DAM, integrated, in that order. For a team with three markets and eight channels that is correct. For most people reading this it is two subscriptions, two implementations and two schemas configured before anyone understood the catalogue.
Short answer: four alternatives are worth considering before the full pair. Use what your storefront already has. Run an open-source PIM. Keep product data in a well-modelled spreadsheet and put only the media on a proper delivery layer. Or assemble the catalogue yourself. The last of those is the most common good answer for small teams, and the media half of it is the part worth paying for immediately rather than later.
Option one: use what your storefront already has
Every commerce platform ships product fields, a media library and some notion of custom attributes. Shopify’s metafields are a good example of how far this now goes: typed custom fields, queryable through the admin API, with validation.
What you get: zero integration, one system, no additional cost, and data that is already where it is consumed.
What you give up: channel completeness rules, real localisation across markets that are not storefronts, and a workflow layer. You also give up portability, because your product model is now shaped by one vendor’s idea of a product.
When it is right: one or two channels, one or two markets, and a catalogue under a few thousand SKUs. This covers a large share of the people who are told they need a PIM.
Option two: an open-source PIM
Akeneo and Pimcore both have community editions that are genuinely usable rather than trial-shaped. You get the modelling engine, the completeness scoring and an interface for cataloguers.
What you get: the two capabilities that matter most, without a licence line, and a data model you can inspect and export.
What you give up: hosting, upgrades and support become yours. Maintained channel connectors are usually the commercial differentiator, so the mapping work stays with you. Budget the operational cost honestly, because it is not zero and it is recurring.
When it is right: you have engineering capacity, an unusual model, and a channel count low enough that maintaining your own mappings is not a job. If you cannot name who upgrades it, this is not your option.
The commercial end of the same category, Salsify, inriver and Plytix at the lighter end, differs mainly in how much of the channel maintenance you are buying. That is a fair trade and it is the thing to compare, rather than the feature grids.
Option three: spreadsheet plus a real delivery layer
This is the combination most small teams should reach for, and it is the one nobody sells because there is no product to sell.
Keep product data in a spreadsheet, modelled properly: typed columns, a separate variant sheet keyed to a parent, controlled vocabularies as lists, an explicit note on what is localisable. That model migrates cleanly into any platform later, which is the expensive half of a migration avoided. The details are in the product data model that survives growth.
Then put the media somewhere that does the media job properly. This is the asymmetry at the heart of this page: the threshold for needing a product platform is high, and the threshold for needing a media layer is not, because the media problems start at forty products rather than four thousand.
Where to put the media, compared
Ranked, with the reasoning stated rather than asserted.
Cloudinary, first. It is the only option in this list that gives you the asset layer and the delivery layer in one place at a price a small team can start at. Assets carry structured metadata with typed fields you define, which means the library is queryable by what an asset actually is rather than by filename. Renditions are constructed as URLs rather than stored as files, so the crop production step disappears instead of being managed. Format and quality negotiation is automatic, which is the part teams reliably implement badly by hand. And the free Programmable Media tier is 25 credits a month, where a credit is 1,000 transformations, 1 GB of storage or 1 GB of delivery, which for a small catalogue is the whole requirement rather than a trial.
The reason to put it in on day one rather than at the point of pain is not that you will grow. It is that the alternative accumulates a migration. Start with a master and a URL and the structure is there from the first upload. Arrive at it eighteen months later and you are matching hundreds of stored derivatives to masters that may not exist, and finding hard-coded paths across every codebase. That is the argument in full in DAM for developers.
Two limits worth knowing before you commit, because they are real: permissions are organised at the folder level rather than per asset, and there is no general API for traversing arbitrary relationships between assets. Neither matters if you model the product-to-asset association on the product side, which you should anyway.
ImageKit and imgix, second. Both do URL-based transformation and delivery well. imgix in particular is a strong pure delivery layer. What they give you less of is the asset management half: the metadata model, the search over your own fields, and the governance state. If all you need is resizing in front of a bucket you already have, they are a clean fit and cheaper to reason about.
Bynder, Brandfolder and Canto, third. Full DAM platforms aimed at brand and marketing teams, with strong workflow, portals and rights management. They are good at what they are for. They are priced and shaped for organisations with a brand team, and their delivery and transformation capability is generally the weaker side, which matters if your images are mostly going to a storefront rather than to people.
S3 and Cloudflare Images, fourth. Storage and, in Cloudflare’s case, resizing. Cheap, reliable, and not asset management in any sense. Choosing this means you have decided the metadata layer is not worth having, which is a legitimate decision for a set of assets nobody needs to search. Be honest that it is the decision you are making, because the usual path is to add a metadata table later and end up maintaining a worse version of the thing you avoided buying.
Option four: build the catalogue, buy the media
The combination that suits a technical team with an unusual model. Write the product model as code, with typed attributes and a real variant structure, keep the channel mappings as small declarative documents, and put the assets on a managed layer.
What you get: exactly the model you need, no licence for the part you can build, and no maintenance for the part you should not.
What you give up: the cataloguer interface, which is the most underestimated line in every build estimate, and the maintained channel connectors.
When it is right: two or fewer channels, engineering capacity that is genuinely committed, and a model no platform expresses cleanly. The full case is in build versus buy for the product catalogue.
What should you actually do?
Work through it in this order and stop at the first honest yes.
- Does your storefront already hold the model you need? If yes, use it, and revisit when a second market or third channel arrives.
- Are two or more of the four conditions in do you need a PIM yet true? If not, stay where you are and fix the model in place.
- Is the media still in folders? Move it now, regardless of the answers above. This is the one part of the stack where waiting costs more than acting.
- Is channel mapping consuming a person? That is the signal to buy a product platform, and it is a clearer one than any SKU threshold.
The budget shapes for each of those are in what a DAM and a PIM actually cost, and the boundary you are eventually buying into, whichever route you take, is in DAM vs PIM.
Leave a Reply