DAM vs PIM

Tag: Cost

The five lines of a real budget, of which the licence is usually the smallest and the content work the largest.

  • Build versus buy for the product catalogue

    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.

    A central card ringed by three dashed circles holding six teal blocks, nine pale blocks and fourteen amber blocks spilling past the outer ring

    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.

    Macro of a stack of printed sheets along the cut edge, orderly for two thirds and fanning into dog-eared amber sheets at the top

    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.

  • What a DAM and a PIM actually cost

    What a DAM and a PIM actually cost

    Every quote you receive will be for the licence. Every project that goes wrong goes wrong on one of the other four lines.

    Short answer: budget the licence at roughly a third of year one and less than half of year two. The lines that get missed are data cleanup before go-live, integration work on both sides, and the ongoing human effort of keeping records complete, which no platform removes and several make more visible. If a business case does not name those three, it is not a business case.

    The five lines

    Licence or subscription. Priced per user, per SKU, per asset, per gigabyte, or per some blend. This is the negotiable one and it is the one everyone negotiates, usually at the expense of attention to the others.

    Implementation. Configuration, schema build, channel mappings, and the integration work on both ends. Frequently sold as a fixed-price package that covers the first two and not the third. Ask explicitly who is building the connection to your storefront, because “we have an integration” often means “there is an API”.

    Data preparation. Cleaning, deduplicating and completing what you already have, before it can be loaded. This is the line most often estimated at zero and it is almost never zero. If your current data were clean you would probably not be buying anything.

    Ongoing content work. Someone still has to write the copy, enter the attributes, tag the assets and approve them. A good system makes this work visible and routes it. It does not do it. This is the largest line over three years and it exists whether or not you buy anything, which is why it is often left out and why leaving it out distorts the comparison.

    Rework. Everything you have to redo because a decision made in month two turned out wrong in month eight. You cannot budget it precisely; you can reduce it by modelling before choosing, which is the argument in the product data model that survives growth.

    What the pricing models actually do to you

    The unit of pricing shapes behaviour more than the price does, and this is worth thinking about before the negotiation.

    • Per user encourages shared logins, which destroys your audit trail and is usually a contract breach.
    • Per SKU makes you reluctant to load the long tail, which is exactly the part of the catalogue that most needs structure.
    • Per asset makes people delete masters to save money, which is the opposite of what an asset library is for.
    • Per gigabyte of storage is mostly benign, since storage is cheap and predictable.
    • Per gigabyte of delivery is fine while you are small and becomes the number to watch if a campaign goes well.
    • Consumption credits pool several of these, which makes the bill harder to forecast and easier to control, because you can trade one kind of usage against another.

    Cloudinary is a public example of the last model, and it is worth reading as a shape rather than as a recommendation at this point in the page. Its Programmable Media plans start at a free tier of 25 credits a month, then $99 a month for 225 credits, and $249 a month for 600. A credit is 1,000 transformations, or 1 GB of managed storage, or 1 GB of delivered bandwidth, spent across those as you use them. Cloudinary Assets, the DAM side, has a free tier at 25 GB of storage with enterprise pricing above it.

    The practical consequence of a pooled model is that a small team can carry a real asset library and real delivery on nothing, which is unusual in this category and which changes the build-versus-buy arithmetic in build versus buy for the product catalogue.

    A long statement on paper with a column of empty line items, teal section rules, four items struck through in amber

    The shape over three years

    Year one is licence plus implementation plus data preparation, and it is the big number. Year two is licence plus the ongoing content work plus whatever integrations you deferred. Year three is where the total cost of ownership comparison actually gets decided, because by then the implementation cost has amortised and what remains is the running cost of the operating model.

    Two patterns are worth expecting.

    The cheap licence with expensive integration. Common in the DAM category. The platform is affordable and every connection to it is a project. Total is higher than the quote by a factor that depends entirely on how many systems you have.

    The expensive licence with everything included. Common at the enterprise end of PIM. The number is large, visible and survivable, and the risk moves from cost to lock-in, because the included integration work is built in a way only that vendor can maintain.

    Neither is a trap exactly. They are different distributions of the same total, and which suits you depends on whether you have engineering capacity or budget, which is rarely both.

    The line nobody quotes: getting out

    Ask two questions in the first meeting, before the demo.

    Can you export everything, including relationships and history, in a documented format, on demand, without a support ticket? The answer determines what you will pay to leave. “We can arrange an export” is not the same answer as “here is the API endpoint”.

    Do your assets keep working during a migration? If URLs are tied to the vendor’s domain and the identifiers are internal, then leaving means changing every URL in every channel, which is a cost you incur once and remember forever.

    Neither question offends a good vendor. The reaction is itself information.

    A teal line falling and flattening against a pale line climbing past it, crossing at eighteen months, marked with a thin amber rule

    What should a small team actually budget?

    Rough shapes, for a team under fifteen people with a few thousand SKUs. These are planning figures rather than quotes, and the point is the ratio rather than the absolute.

    • Do nothing yet. Spreadsheet plus the storefront’s own fields and media library. Cost is the content work, which you are already paying. This is the right answer more often than the category admits, and do you need a PIM yet is the test.
    • Media layer only. A delivery and asset platform on a free or low tier, no PIM. Costs tens per month at small scale, removes the crop and format work permanently, and is reversible.
    • PIM only. Entry tiers in this category start in the low hundreds per month. Add the same again for implementation in year one, and count on someone spending real time on channel mappings.
    • Both, properly implemented. Assume a five-figure year one including implementation, and half of that ongoing. If the quote is materially below that, check which of the five lines has been left out.

    The alternatives to spending any of it, including what you can assemble from tools you already pay for, are in alternatives to buying a DAM and a PIM. The boundary question that determines whether you need one system or two is in DAM vs PIM.