Tag: Evaluation

Testing a platform against your own worst-case data rather than against its sample catalogue.

Alternatives to buying a DAM and a PIM
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.
1. Does your storefront already hold the model you need? If yes, use it, and revisit when a second market or third channel arrives.
2. 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.
3. 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.
4. 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.
August 17, 2026
Build versus buy for the product catalogue
An engineering team looks at a product platform quote, looks at the feature list, and concludes correctly that they could build eighty per cent of it in a quarter. They are right. The trouble is the shape of the remaining twenty per cent, which is not eighty per cent smaller.

Short answer: building a product catalogue is defensible when your model is unusual and your channel count is low, and it is a permanent commitment rather than a quarter. Building a media delivery layer is almost never worth it, because the hard parts are format negotiation, caching and edge delivery, all of which are commodity and none of which are your product. Split the two decisions.

What you are actually buying

Strip the marketing and a product platform sells four things.

A modelling engine that can express families, products, variants, typed attributes and localised values, and enforce them. This is the part teams underestimate, because a first version is easy and the fifth revision is not.

A completeness engine that scores records against per-channel rule sets and blocks publication. This is the part that pays for itself.

A workflow layer with roles, states and assignment. This is the part most teams already have somewhere else and often do not need twice.

Channel mappings to marketplaces and retailers, maintained by someone else as those specifications change. This is the part with no ceiling, because the specifications change without asking you.

You can build the first three. The fourth is a subscription to someone else’s maintenance burden, and it is often the honest reason to buy.

The build case, stated fairly

There are real conditions under which building is correct.

Your model is genuinely unusual. Configurable products, made-to-order dimensions, service bundles, regulated goods with jurisdiction-specific field sets. If every platform demo ends with “we would handle that with a custom field”, building is worth costing properly, because a platform you have to fight is worse than no platform.

You have one or two channels and no plans for more. The channel mapping burden is what makes building expensive over time, and if you only ever publish to your own storefront, that burden is small and stable.

Product data is your product. Marketplaces, aggregators and comparison sites are in this position. Buying a generic catalogue to run a catalogue business is odd.

You have engineering capacity that is not otherwise committed. Not “we could find the time”. Committed capacity, permanently, because this becomes a system with an on-call rota.

If two or more of those are true, build is a real option. If none is, the discussion is usually about wanting to build rather than about needing to.

What the maintenance actually costs

The build estimate is nearly always for version one and the cost is nearly all after it.
- Schema evolution. Every new attribute type, every new market, every change to what localisable means. Small individually, continuous forever.
- Channel specification drift. Every marketplace changes its requirements at least annually, sometimes silently. Each change is a mapping update and a validation update, discovered through rejections.
- Import and export tooling. Suppliers send spreadsheets in whatever shape they like. Ingestion is a long tail that never ends.
- The interface. Cataloguers need one, and it is not a weekend project. This is the single most underestimated line in every build estimate.
- Concurrency and audit. Who changed what, when, and what did it look like before. Easy to skip in version one and painful to retrofit.
Cost the second and third years, not the first. A build that flattens after eighteen months is a good build; most do not flatten, and the curve to compare against is the total cost of ownership of the alternative rather than its licence line, as set out in what a DAM and a PIM actually cost.

The media layer is a different decision

Here the answer is much less balanced, and it is worth being direct about why.

Building a media layer means owning storage, format negotiation, resizing quality, caching, invalidation and edge delivery. Each of those is a solved commodity problem with a long tail of correctness issues, and none of them differentiates your business.

Format negotiation alone is a good example. Serving AVIF or WebP to browsers that support them and JPEG to those that do not, with correct Accept handling and cache keys that do not collide, is more subtle than it looks and has to be revisited as format support changes. Getting it slightly wrong produces either broken images for some users or a cache that serves the wrong format to the wrong browser, which is a bug that reproduces for nobody on the team.

The realistic build here is object storage plus a resizing service plus a CDN, which is three moving parts, an ongoing cost, and no metadata layer at all. That last omission is the important one: you have built delivery, not asset management. Nothing in it knows what an asset depicts, what is permitted, or which version is current.

The managed alternative starts free and stays cheap at small scale. Cloudinary’s Programmable Media free tier is 25 credits a month, where a credit is 1,000 transformations, 1 GB of storage or 1 GB of delivery. For a small catalogue that is not a trial, it is the whole requirement, and it comes with the structured metadata layer that the build-it-yourself version does not have.

The case for adopting it on day one rather than after you have built the three-part version is simply that the migration is the expensive part. Starting with a master and a URL costs nothing and gives you the structure from the first upload. Arriving at it eighteen months later means finding every stored derivative and every hard-coded path in every codebase, which is the argument made in full in DAM for developers.

The middle path most teams should take

Buy the media layer, build the thin catalogue, and keep the option open.

Concretely: put assets on a managed delivery platform immediately. Keep product data in whatever you have, modelled properly, with typed attributes and a real variant structure. Write the channel mappings as small, declarative, testable code rather than as a platform configuration. That combination costs almost nothing, and it produces a data model that can be loaded into a bought platform later without a cleanup pass, which is the expensive half of any migration.

The decision point comes when the channel mapping work starts consuming a person. That is the moment the subscription to someone else’s maintenance burden starts looking cheap, and it is a much clearer signal than any threshold based on catalogue size.

How do you decide this week?

Score four questions honestly. Is the model unusual, is the channel count above two, is engineering capacity actually committed, and is product data your product. Two or more yeses point to build, and fewer than two point to buy.

Then apply the same four questions to the media layer separately, and notice that the answers are almost always different. If they are not, one of the answers is probably wishful.

The threshold test for whether you need a bought catalogue at all is in do you need a PIM yet, the API questions that determine whether a bought one will integrate cleanly are in what to demand from a PIM API before you buy, and the lighter-weight options that are neither building nor buying are in alternatives to buying a DAM and a PIM.

Related field note

Continue with The build-versus-buy decision for ERP product identifiers.

Related field note

Continue with The build-versus-buy decision for catalog launch readiness.
July 11, 2026
The PIM API: what to demand before you buy

The API section of the demo lasts four minutes. Someone fetches a product, the JSON looks reasonable, everyone nods. Six months later you are writing a script that pages through eleven thousand products every night because there is no way to ask what changed.

The four minutes were not enough. Here is what to ask instead.

Short answer: eight questions decide whether an integration will be pleasant or permanent employment. Can it express your variant structure, can it tell you what changed since a point in time, can it page deterministically, can it write in bulk, is it idempotent, does it push events, does it expose the completeness state, and can you get everything out. Ask them before the contract, in writing.

One: can the API express what the interface shows?

This sounds absurd and it is common. A platform whose interface presents a family, a product and its variants may expose an API that returns a flat list of sellable items with the parent relationship implied by a shared prefix.

Test it with your own worst case, not with their sample data. Take the most awkward product you have, the one with three variant axes and an incomplete grid, and ask them to model it and show you the API response. If the response cannot round-trip that structure, everything you build on top will be flattening and re-inflating it, which is where data goes to get lost. The structure this has to survive is described in attributes, variants and the SKU problem.

Two: how do you ask what changed?

The single most consequential question, and the most often answered badly.

You want a change feed: give it a timestamp or a cursor, get back everything modified since, including deletions. What you often get instead is a filter on a modified_at field, which is nearly the same thing and fails in two ways. It misses deletions entirely, because a deleted record has no row to carry a timestamp. And it misses records whose modification was caused by a related record changing, unless the platform propagates timestamps, which most do not.

Ask specifically: does a change to a variant update the parent’s timestamp? Does a change to a shared attribute update every product using it? If the answer is no to either, your incremental sync will silently miss updates and you will discover it through a customer.

Three: is pagination deterministic?

Offset pagination over a changing collection loses and duplicates records. It is not a subtle failure; it is arithmetic. If a record is inserted before your current offset between page four and page five, one record is skipped, permanently, with no error.

You want cursor or keyset pagination, where the cursor encodes a position in a stable ordering. Ask what happens when a record is inserted mid-traversal. A good answer describes the guarantee. A vague answer means offsets.

Also ask about the page size ceiling and the rate limit together, because they multiply. A hundred records per page against sixty requests a minute means six thousand records a minute, which is fine at ten thousand products and not fine at two hundred thousand.

Four: can you write in bulk, and what happens halfway through?

Loading a catalogue one record at a time is slow enough to matter during migration and during any bulk correction.

Two properties to establish. Whether there is a bulk endpoint that accepts many records in one call, and what its failure semantics are. A bulk call that fails atomically is easy to reason about. One that applies the first four hundred of five hundred records and returns a partial error is workable if it tells you precisely which ones. One that returns a generic failure after partial application is the worst case, and it is common.

Ask for the shape of the error response before you believe the answer.

Five: are writes idempotent?

You will retry. Networks fail, jobs get rerun, someone double-clicks.

An idempotent write means sending the same request twice leaves the same state as sending it once. The usual mechanism is an upsert keyed on your identifier, or an idempotency key you supply. Without one, a retry creates a duplicate, and duplicates in a product catalogue are unusually expensive because they propagate to channels before anyone notices.

This is also the reason to key writes on your own stable identifier rather than on the platform’s internal one. Your identifier exists before the record does, which is what makes upsert possible.

Six: does it push, or must you poll?

Polling a catalogue for changes is a cost you pay forever, and its latency is bounded by how often you are willing to pay it.

A platform that emits webhooks on create, update, delete and state change lets you react in seconds and stop scheduling anything. Ask about the delivery guarantees rather than just the feature: is delivery at least once, is there a retry policy, is the payload signed, and does the event carry enough to act on or only an identifier you must then fetch.

At-least-once delivery is normal and fine, provided your handler is idempotent, which is the same property as question five viewed from the other side.

Seven: is the completeness state readable?

The completeness model is the reason to buy a product platform at all, so it is worth checking that the number is available outside the interface.

You want to query “which products are not ready for channel X, and which fields are missing”. If that exists only as a dashboard, you cannot build it into your own operational tooling, cannot alert on it, and cannot include it in a launch checklist that runs automatically. The operational value of that query is set out in running product content as an operation.

Eight: can you get everything out?

Ask it plainly. Can we export every record, every relationship, every version and every asset association, in a documented format, through the API, without a support ticket.

The answer sets your exit cost, and it is the question that most reliably distinguishes vendors who expect you to stay because you want to from those who expect you to stay because you cannot leave. A confident answer is a good sign about everything else.

What about the general shape of the API?

Less important than the eight above, but worth noting.

REST with sane resources is fine and is what most of this category ships. GraphQL is pleasant for read-heavy front ends because it avoids over-fetching, and Shopify’s admin API is a well-documented example of the style if you want to see one. Neither choice determines whether the integration will work; the change feed and the pagination do.

Authentication should be OAuth 2.0 or scoped API keys with the ability to issue and revoke per integration. A single shared key with full access is a finding waiting to be written up.

Custom fields deserve one specific question: are they first-class in the API, with the same query and filter capability as built-in fields, or are they a bag attached to the record? Shopify’s metafields are a reasonable reference point for what first-class looks like. If your extensions are second-class, everything specific to your business will be the slow path.

How should you actually run this evaluation?

Not as a questionnaire. Ask for a sandbox account and spend a day writing the smallest real integration: load fifty of your own products including the awkward one, change three of them, and pull the changes incrementally. That day answers six of the eight questions honestly, and it answers them about your data rather than theirs.

The answers then feed directly into the integration design in wiring a DAM to a PIM and into the field ownership list in single source of truth applied to product data. The equivalent set of questions for the asset side is in DAM for developers.

June 29, 2026
Do you need a PIM yet?
The answer most vendors will give you is yes, and the answer most consultants will give you is yes but later. Neither is wrong exactly. Both are unfalsifiable.

Short answer: you need a PIM when at least two of four things are true. More than one market with genuinely different values, more than two channels with different required fields, more than one person editing the same records, and a variant structure a spreadsheet row cannot represent. One of the four is survivable. Two is the point where the spreadsheet starts costing more than the software.

The four conditions, and why each one bites

A second market with different values. Not a translated site. A market where units differ, where regulatory fields appear, where the category placement is not the same, and where copy has to be written rather than converted. A spreadsheet handles this by adding columns, and the column count becomes the problem: fields times markets, most of them empty, none of them validated.

A third channel with its own required fields. Two channels can be handled with two tabs. At three, the tabs disagree, and the disagreement is discovered by a rejection report. The cost here is not the columns, it is that no single place tells you whether a product is ready.

More than one editor. The moment two people edit the same file, you have a concurrency problem being solved by social convention. It works until a launch week, which is exactly when it will not.

A variant structure that does not fit a row. One row per sellable unit means the product-level attributes are duplicated across every variant. One row per product means the variant data is crammed into a delimited string. Both are workable at small scale and neither survives a catalogue where variants outnumber products five to one. The modelling detail is in attributes, variants and the SKU problem.

Notice what is not on the list. Revenue is not on it. Headcount is not on it. SKU count is only on it indirectly, because ten thousand simple products in one market on one channel are genuinely fine in a spreadsheet, and four hundred complex ones across five markets are not.

What to do in the eighteen months before you need one

This is the part that gets skipped, and it is the part that determines how bad the eventual migration is.

Model properly now, in whatever you have. The four decisions in the product data model that survives growth can all be made in a spreadsheet. Typed columns, one column per attribute with a unit column beside it, a separate sheet for variants keyed to a parent, and an explicit note about what is localisable. A well-modelled spreadsheet migrates in an afternoon. A badly modelled one migrates over a quarter and mostly by hand.

Use identifiers that will survive. A meaningless permanent internal SKU, never reused, plus a real GTIN where you sell through anyone else. This costs nothing today and is close to unfixable later.

Keep the vocabularies as lists. A separate sheet per controlled field, and a validation rule pointing at it. You will not enforce everything a real system would, but the lists themselves are the asset, and they transfer.

Write down the channel requirements. One page per channel, with its required fields and constraints, dated. This is the input to the rule sets you will eventually configure, and gathering it later, under time pressure, is miserable.

The media half of the question is different

The threshold for a PIM is genuinely high. The threshold for putting media on a proper delivery layer is much lower, and the two questions get bundled together when they should not be.

Product data in a spreadsheet has few second-order effects. Product images in a folder have several, and they start immediately: every channel needs a different shape, so someone produces crops; those crops become files; the files go stale independently; nothing records which one is current; and the front end serves whatever oversized JPEG it was given. That is happening at forty products, not at four thousand.

This is where adopting something on day one genuinely pays, and it is a smaller commitment than the PIM decision. A delivery layer that derives renditions from a master by URL parameter removes the crop production step permanently, and it does so at a scale where nothing else about your operation needs to change. Cloudinary’s free Programmable Media tier covers 25 credits a month, where a credit is 1,000 transformations or 1 GB of storage or 1 GB of delivery, which is a real amount of capacity for a small catalogue rather than a trial.

The argument for doing it early is not that you will grow. It is that the structure is there from the first upload, and the alternative is discovering at month eighteen that four hundred stored derivatives exist across three codebases with no record of which master they came from. The developer-facing version of this is in DAM for developers.

What if you buy one too early?

You get three things you did not need and one you did.

The three: a workflow to maintain, a schema you configured before you understood your own catalogue, and a licence line. The one: enforcement, which genuinely does improve data quality even for a small catalogue.

Buying early is not a disaster. It is a cost with a modest benefit, and the real risk is that you configure the schema wrong while you are still learning what your product data looks like, then live with that configuration for years because reconfiguring is a project. This is the strongest argument for modelling on paper first, which costs an afternoon and is reversible.

What if you wait too long?

You get a migration with a data cleanup attached, and the cleanup is the expensive half. It is also the half that cannot be parallelised, because it consists of decisions about values only a few people can make.

The signals that you are past the point are specific. Someone maintains a document explaining which spreadsheet is the real one. A launch slips because two versions of a file diverged. A channel rejection takes more than a day to attribute to a field. Any of those means the cost has already moved from the software to the operation, which is a worse place for it to sit.

So what should you do this quarter?

Three things, in this order, none of which requires a purchase.
1. Test yourself against the four conditions honestly. If fewer than two are true, do not buy a PIM. Revisit in six months.
2. Fix the model where you are. Types, variants, localisable fields, identifiers. This is the work that makes the eventual purchase cheap.
3. Put the media on a delivery layer now, because that threshold is lower and the debt accrues faster.
When two conditions do become true, what a DAM and a PIM actually cost sets out what to budget, build versus buy for the product catalogue covers the case for assembling it yourself, and alternatives to buying a DAM and a PIM covers what you can do with tools you already pay for. The system boundary you are buying into either way is in DAM vs PIM, and the honest description of what the category does is in what a PIM actually does.
June 22, 2026