Your CMS and Your Marketplace Are Not the Same Purchase
Part 1 argued that programmatic is a transaction mechanism, not a demand strategy. Part 2 showed that whether it helps or costs you depends on where your market sits — concentrated or fragmented. Part 3 traced the pattern of a middle layer forming, then consolidating, then starting to set terms on the operator’s behalf. Part 4 named what that looks like once it’s happened: pricing control quietly moving to a mechanism built to clear volume, not protect one specific asset — the absentee landlord position. This part is about the single decision that makes that position hardest to reverse.
Buying the CMS and the marketplace as one purchase.
Two systems get sold together more and more often — sometimes as a bundle, sometimes as a condition of access. They do different jobs. A content management system runs the screens: player uptime, scheduling, device health, proof of play, who on the team can touch what. A marketplace prices and sells the inventory: which buyers reach it, through what channel, at what floor. One keeps the asset running. The other decides what it earns. Treating them as one purchase because a vendor happens to offer both under one contract is a design choice — and like most design choices, its consequences show up years later, at renewal, not at signing.
There’s a name for that design choice, and a body of work worth borrowing from to reason about it. Carliss Baldwin and Kim Clark spent much of Design Rules, Volume 1: The Power of Modularity (MIT Press, 2000)¹ studying why some systems are built modular — separate components connected through a defined interface, each replaceable on its own — and others are built integral, where components are coupled so tightly that changing one means redesigning the whole. Their case studies were computers and industrial products, not vendor contracts — what transfers here is the design logic, not a literal application: a modular system lets you swap one component without touching the rest; an integral one doesn’t. A CMS and a marketplace are two components. The interface between them is a small, well-understood set of exchanges — availability, delivery instructions, playback confirmation. Whether that interface stays documented and open, or gets absorbed into one vendor’s black box, decides whether the stack is modular or integral, whatever the sales conversation called it.
Figure 1 — the same two functions, built two different ways
Why a vendor prefers the integral version
There’s a straightforward commercial reason a vendor selling both prefers to bundle them: it raises the cost of leaving, which raises the value of the relationship on their side of the table. That’s not a hidden trick — bundling to raise switching costs is a well-worn strategy across enterprise software generally, not something specific to DOOH vendors. The operator’s job isn’t to treat the incentive as bad faith. It’s to recognize that it exists and price it into the decision before signing, not after.
Here’s the part worth holding onto while that conversation is happening: whatever its flaws, the CMS already running has already proven it works, under the network’s actual conditions, at its actual scale. A new one hasn’t. That’s a real asset on one side of the ledger, whether or not the vendor doing the bundling mentions it.
What exit actually costs
The question worth asking before signing, not after: if the CMS needed replacing while keeping the marketplace — or the reverse — is that actually possible? Or does the contract require keeping both regardless, paying for features that arrived bundled but aren’t used, or limited to whatever the CMS happens to already integrate with? If the honest answer is that one can’t be replaced without the other, that’s an integral system, whatever it was called at signing — and the switching cost has already been paid, just not yet in cash.
None of this is an unusual technical ask. Integration through a documented interface — availability, delivery instructions, playback confirmation — is standard practice for systems built to be replaceable; it isn’t a specialist feature reserved for enterprise deals. A marketplace that respects the boundary connects to whatever CMS is already running and stays out of the parts of the operation it has no reason to touch.
Where the payoff shows up
It shows up in the ordinary case, not the dramatic one. When the two layers stay modular, replacing an underperforming SSP is a component swap — the CMS doesn’t notice, the screens don’t notice, operations don’t skip a beat. When they’re integral, replacing either one means touching the system the whole network runs on. That’s the point at which a vendor relationship stops being just a vendor relationship.
Figure 2 — the assembled system: order-of-sale, the documented API, and where a third-party CMS plugs in
Notice what the diagram doesn’t show: which CMS is running underneath. The order-of-sale sequence and the documented API sit above that choice entirely — the commercial layer works the same way whether it’s talking to the primary CMS or to any other one, which is the whole point. If swapping the box at the bottom of that diagram would break the top of it, the interface was never really documented in the first place.
The same logic applies one level up, inside the commercial layer itself. Routing all demand through a single SSP concentrates the same risk in a different place. Keeping more than one channel live — with the ability to enable or disable each one actually working in practice, not just on paper — keeps the same leverage on the operator’s side that Part 2 described for exchanges generally.
The test that ties it together
No exchange, no SSP, no DSP, no marketplace creates the value a screen already has. At best, each one helps sell what the location was already worth. The moment a vendor relationship starts deciding that value instead of helping realize it, the system has moved from modular to integral, whatever the org chart says.
Confirm the interface, not just the intent. Ask for the documented specification — availability, delivery instructions, playback confirmation — rather than a verbal assurance that “of course it integrates.” An interface no one can see isn’t one worth relying on.
Price the exit before the entry. Get, in writing, what replacing the CMS alone or the marketplace alone actually costs — migration effort, lost functionality, time — before signing either one, not after.
Keep more than one channel live. A single SSP, or a single CMS-marketplace bundle, concentrates the same risk Part 2 described for a single exchange. Optionality is worth paying a little for.
If a network is already bundled, the fix rarely starts with new technology. It starts with finding out, in practice, whether the two systems can actually be separated — and what it costs to find out.
Next in this series: the screens are already built. What’s still on the table that most networks aren’t using yet.
Where does your stack sit — modular enough to replace one piece without touching the rest, or one purchase away from finding out it wasn’t?
Sources
- Baldwin, C.Y. & Clark, K.B. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. https://direct.mit.edu/books/monograph/1856/Design-Rules-Volume-1The-Power-of-Modularity
