The asset you never took delivery of

Consider what a company actually buys when it commissions a website, a campaign or an identity.

There is the deliverable, and that turns up. There is also a set of things that were made in order to produce the deliverable and which usually do not arrive: the working files, the source footage, the fonts and their licences, the component library, the analytics configuration, the DNS records, the hosting account, the CMS schema, the accounts with whatever third-party services the thing depends on to run.

Some of those are conventionally handed over. Many are not, and the ones that are not tend to be the ones that determine whether the work can be maintained, extended or moved by anyone other than the supplier who made it.

This is a recognisable problem with a literature. Oliver Williamson built much of transaction cost economics on what he called asset specificity: assets that are worth a great deal inside one particular relationship and much less outside it.¹ Where such an asset exists and control of it sits with one party, the other party is exposed to what the literature calls hold-up. Not necessarily malice. Simply a situation in which one side's continued cooperation is required and the terms of that cooperation were never agreed.

A brand system is close to a textbook case. It is enormously valuable to the company it was made for and nearly worthless to anyone else, and the working version of it commonly lives on a machine, in an account and in a file format controlled by whoever made it.

Where it actually goes wrong

The usual framing is trust, and trust is not the issue. Most of these relationships end amicably and most suppliers behave well. The failures are administrative.

A project closes. The team that ran it moves on. Nobody is paying attention to a hosting account that renews annually on a card belonging to someone who has since left, or to a domain registered under a personal email, or to a plugin licence that lapses. The site keeps working, because sites keep working long after anyone is looking after them, which is what keeps it invisible until it is not.

Then a card expires, or a platform changes its terms, or a company is acquired and its new owners ask for the source files, and the answer takes three weeks to assemble or does not exist.

The scale is easy to underestimate. On one studio's own infrastructure, a clean-out found twelve server instances still running: a decade of client work and its own earlier sites, four fixed addresses, sixteen snapshots, none of it edited since the week each project went live, all of it billed for years. The point is not the cost, which was trivial. It is that a decade of work for other people had been sitting in one supplier's account, and nobody on either side had thought about it since the invoices were paid. On the same sweep, 864 files were recovered from a backup that had become, without anyone deciding it, the only copy of a body of work.

Projects closed for years still depended on a company that had stopped thinking about them.

The situation is getting worse, not better

The intuitive assumption is that modern tooling improves this. Everything is in the cloud, nothing is on a dusty server, therefore custody is simpler.

The opposite is true, and the mechanism matters.

When work was delivered as files, custody was a physical question with a clear answer. A handover was a transfer of things. Whatever else was wrong with that arrangement, a company that held the files held the asset.

Work is now delivered into platforms. The site lives in a hosted builder, the design in a collaborative canvas, the assets in a shared drive, the content in a service, the analytics in another, each with its own account, seat structure, export format and terms. The asset is no longer a set of files. It is a position in several companies' systems, and a position is not transferable in the way a file is.

Export formats are lossy by design, and not usually for sinister reasons: a builder that exports perfect, portable output has made itself easy to leave. Reduced portability is a rational product decision for a platform and a slow accumulation of specificity for everyone building on it. The result is that a company's most valuable relationship-specific asset increasingly cannot be handed over at all, only re-created.

So the classical hold-up problem has not gone away. It has moved one layer down, from the supplier who made the work to the platform the work was made in, and it is now shared by every company in the market rather than negotiated bilaterally.

Why this belongs in the contract and not in the relationship

The reason to settle this at contract stage rather than at the end sits in Williamson's framework, stated plainly: the moment to agree terms is before either party has made the specific investment, because afterwards the bargaining position has already shifted.

Asking for source files at the end of a project is a favour. Specifying them at the start is a term. They cost the same to produce and they are not the same thing, and any supplier worth working with will agree to the second without discussion.

The clauses that matter are short.

Delivery of working files, not only outputs. Named formats, with the working versions rather than flattened exports, delivered at project close as a condition of final payment.

Accounts in the company's name from the outset. Hosting, domain, analytics, CMS, third-party services. The supplier is granted access to accounts the company owns, rather than the company being granted access to accounts the supplier owns. This single reversal removes most of the failure modes in this essay and costs nothing to implement on day one.

A named exit procedure. What is handed over, in what format, within how many days of termination, and what the supplier will do to assist a successor. Agreed while everyone is enthusiastic.

Licences transferable or separately held. Typefaces in particular. A licence held by an agency for a client's brand typeface is a dependency almost nobody discovers until they try to leave.

A custody review on a calendar. Once a year, someone lists what the company depends on, who holds it, and on whose payment card. This takes an afternoon and is the only item here that must recur.

The part worth arguing about

There is a reasonable objection to all of this, which is that most companies will never need any of it. A relationship that continues indefinitely never tests custody, and the effort of specifying it is insurance against an event that may not occur.

That is a fair reading of the base rate and it misses where the cost falls. The exposure is not distributed evenly across time. It concentrates at the moments when a company is least able to absorb it: an acquisition, where diligence asks who owns the marks and the files; a funding round, where a dependency on a supplier's personal accounts is an unwelcome discovery; a change of agency; the departure of the one person who knew where things were.

The value of custody is nearly zero for years and then briefly enormous, which is the general shape of insurance and the general reason it goes unbought.

What this says about buying creative work

The wider point is about how companies specify what they are purchasing.

A brief typically describes the deliverable: what it looks like, what it says, when it ships. It rarely describes the conditions under which the company will still control the work in three years, which is a separate question and often the more consequential one.

A company that commissions well asks two questions rather than one. What are we getting, and what will we hold. The first is what the industry is organised to answer. The second determines whether the first was worth paying for, and it is asked, in my experience, almost never.