Replacing a $30K Digital Asset Manager with $600 of Cloudflare

Annual cost

~$600from $30,000+ quoted

Brands served

7one portal each

Downloads

5,852381 unique users

The problem

Distributors, retailers, and on-premise accounts constantly need brand assets: a high-resolution label for a shelf talker, a bottle shot for a menu, a tech sheet for a buyer meeting. At a seven-brand wine company, those requests all landed in the same place — the marketing and web team's inbox.

The existing process was email and shared drives. Someone would ask for the current Cabernet label, a person would go find it, and a 40MB file would go out as an attachment or a link that expired. Nobody could tell which version was current. Nobody could tell what had been downloaded, by whom, or whether a partner was still using artwork from two vintages ago.

The obvious fix is a digital asset management platform, and there are good commercial ones. The quotes came back above $30,000 a year. For a company where the entire web budget had to cover hosting, e-commerce, and a team, a five-figure line item for file storage with a login screen was not going to survive a budget review — and honestly, it shouldn't have.

What I actually needed

Working backwards from the requests we were already fielding, the real requirements were narrower than what the commercial products sell:

• A branded, public-facing portal per brand, so a distributor sees B.R. Cohn's assets under B.R. Cohn's identity rather than a generic vendor login.
• Fast downloads of large files from anywhere, without the marketing team acting as a file server.
• One current version of every asset, so there is no ambiguity about what is approved.
• Enough analytics to answer "what are partners actually using?" — which turned out to be the question leadership cared about most.

What I did not need was most of a commercial DAM: approval workflows, InDesign plugins, AI tagging, rights management for a media library we didn't have. The gap between what was for sale and what we needed was the whole argument for building it.

How it's built

The entire thing runs on Cloudflare's platform, which is what makes the economics work. There is no origin server, no VM, and nothing to patch.

• Workers Application logic, routing, auth, and signed download URLs — running at the edge.
• R2 Asset storage. No egress fees, which is the single most important line item when the product is people downloading large files.
• D1 Asset metadata, brand configuration, users, and the download log.
• KV Session and configuration caching for reads that shouldn't touch the database.
• Pages The front end for each brand portal and the internal admin.

R2 is the piece that decides the cost. Traditional object storage bills for egress, so a DAM — a product whose entire purpose is people downloading big files — is exactly the workload that makes those bills unpredictable. R2 charges for storage and operations but not egress, which turns a variable cost that scales with the thing you want to happen into a flat, forecastable one.

The part that mattered more than the savings

The cost reduction is the headline, but the analytics turned out to be the more useful outcome.

Once every download was logged, we could answer questions the old process made impossible. Which brands do partners actually request assets for? Which SKUs get pulled before a selling season? Which accounts are active and which have gone quiet? Which assets has nobody touched in a year, so we can stop maintaining them?

That reporting was not in the original brief. It became the feature people asked about, because it converted a support burden into a source of information about partner behaviour that the business did not previously have.

What it cost, honestly

The ~$600/year figure is infrastructure: Workers, R2 storage, D1, and the domain. It does not include my time to build it, and any comparison that ignores that is not a fair one.

The reason the trade still works is that the build was bounded. This is a well-understood problem — store files, serve files, log the serving — and the platform primitives do most of the heavy lifting. There was no novel infrastructure to design and nothing to keep running once it shipped. The maintenance cost since launch has been close to zero, which is the actual test of whether a build-versus-buy decision was correct.

I would give different advice for a different shape of problem. If we had needed approval chains, per-market rights, or deep creative-tool integration, the commercial products earn their price and I would have said so.

Where it went next

The pattern generalised. I later rebuilt it as Trade Pourtal, a multi-tenant version with custom-domain branding, role-based access control, version history, and audit logging — the same core idea, productised so it isn't tied to one company's brand list.

Working on something similar? If you're weighing a commercial platform against a focused build, I'm happy to talk through where the line actually falls.