Ask a vendor what a DAM costs and you get a licence figure. Ask a team eighteen months into a rollout and you get a different, larger number, and they will not itemise it because most of it never appeared on an invoice.
Short answer: budget the licence at roughly a third to a half of your first-year cost. The rest is schema design, metadata backfill, integration work and the ongoing time of whoever owns the taxonomy. Public pricing is genuinely useful for comparison where it exists: Cloudinary publishes its plans openly with a free tier and no card required, which is rarer in this market than it should be.
The three pricing models
Every DAM prices on one of these, and each one fails in a different direction.
Per seat. Simple to forecast, punishing to adoption. The moment access costs money per person, someone starts sharing logins or emailing files out of the system, and you have quietly recreated the shared drive alongside the library you are paying for. Per-seat pricing suits small closed teams and is actively hostile to the case where an agency, a reseller network or a regional office needs occasional access.
Per storage volume. The most honest-looking model and the most misleading. Storage is the cheapest input in the entire stack and it keeps getting cheaper, so a price anchored to gigabytes is a price anchored to the wrong thing. It also penalises exactly the behaviour you want, which is keeping originals at full quality.
Per usage. Consumption across operations, storage and delivery together. Harder to forecast, but it scales with value rather than with headcount or with a commodity. Cloudinary's credit system is one version: a credit covers 1,000 transformations, or 1 GB of managed storage, or 1 GB of delivered bandwidth, spent across those as you use them. The free tier is 25 credits a month, which is a real amount of work rather than a token.
The practical advice: model your actual pattern against all three before shortlisting. A team with 60 occasional users and 200 GB will get a completely different ranking than a team with 6 heavy users and 20 TB, and the vendor whose model happens to suit you is worth more than the vendor with the better feature list.
What is not on the pricing page
Five lines that land in year one and are almost never budgeted.
- Schema design. Getting twelve fields and three controlled vocabularies agreed across marketing, legal and design. Measured in meetings, not hours, and it is the phase that determines whether anything else works.
- Metadata backfill. Automated tagging handles a lot of the descriptive layer now, but approval state, licence terms and expiry are human judgements. Estimate the assets that need it, multiply by two minutes, and do not flinch at the result.
- Integration. Connecting the library to the CMS, the storefront, the feed generator and whatever else consumes assets. Cheaper when the platform is API-first, which is one of the practical arguments for a headless approach.
- The taxonomy owner. A named person with allocated time, indefinitely. Not a project role. Skip it and the controlled fields decay into free text inside a year.
- Migration. Path extraction, mapping, ingest and correction. Scales with how long you waited, and the detail is in migrating off shared drives.
Rule of thumb that has held up for me: if the licence is X, budget between X and 2X for year one, and about 0.3X annually after that.
What is the cost of not having a DAM?
This is the harder number and the one that actually decides the business case, because it is currently being paid and nobody is counting it.
Re-creation. Assets remade because nobody could find the original. Re-shoots are the visible version; the common version is a designer spending forty minutes rebuilding a layered file that existed. Ask your design team for an honest estimate of this per month and it will be higher than you expect.
Rework from wrong versions. Something shipped with the superseded logo, the old packaging, the discontinued colourway. Cost is the correction plus whatever it went out on.
Licensing exposure. Stock imagery used past its term, model releases that lapsed, agency work used outside the contracted channel. Low frequency, high severity, and entirely invisible until it is a letter. This is the line that justifies the purchase on its own in regulated or consumer-facing businesses.
Search time. Small per instance and enormous in aggregate. Every "do we have a landscape version of this" costs two people ten minutes.
Delivery waste. Oversized images shipped because no pipeline was resizing them. This one is measurable today: image weight is still among the most common causes of a slow largest contentful paint, and the Web Almanac media chapter is a reasonable reference for how widespread the problem remains.
Build versus buy
Occasionally reasonable, usually not, and the deciding factor is not the build.
Object storage plus a database plus a transformation service is a weekend for a competent team, and it works. What you have built is the easy sixty percent. The remaining forty is metadata schema management, versioning, approval workflow, controlled vocabularies, a UI non-technical people will tolerate, access control and permanent maintenance of all of it. That is not a weekend, and it is not a project either, it is a product with an ongoing owner.
Build when asset handling is genuinely core to what you sell and the requirements are unusual enough that no vendor fits. Buy otherwise. If the honest reason for building is that procurement is slow, fix procurement.
Getting a real number
Three steps, in order, and none of them involve a demo.
- Count your active assets, not your total. The number that matters is what gets used, requested or modified in eighteen months, and it is usually under ten percent of the drive.
- Model twelve months of usage against each pricing shape. Seats, storage and consumption. The rankings will differ and one model will be obviously wrong for you.
- Run a free tier for two weeks with two hundred real assets. You learn whether your team fills in fields, which no pricing model can tell you.
Do that before you decide, and check the prior question too, because the cheapest DAM is the one you correctly decided not to buy: do you need a DAM yet returns no more often than vendors suggest. If the answer is yes, the platform comparison sorts the market by fit, and what digital asset management actually is sets out what you are paying for.