Technology ownership isn't the same as building everything in-house
Published: 05 Oct 2026
Author:
Anastasia-Nikita Bansal
Large publishers increasingly find that a standard monetisation stack gives them less control than their strategy now requires. In AOP and Deloitte's latest index, 62% of publishers reported revenue growth, even as aggregate participant revenue fell 4.55% year on year. The publishers pulling ahead are the ones differentiating their audience, product, and revenue strategies. Publishing is being rebuilt in every direction at once: apps, registration walls, AI initiatives. The monetisation stack belongs on that list too, and ownership is what publishers should be aiming for.
Off-the-shelf was built for the average publisher
Today, large publishers have access to first-party data, direct advertiser relationships, video and audio inventory, and their own curated deals. A mid-market site selling standard display has significantly different needs.
A standardised “off-the-shelf” product is likely to be built around what the two have in common: standard display formats, a shared set of demand integrations, and inventory sold in the open auction. That is the most competitive and least profitable layer of the stack, and for a large publisher it is the smallest part of what the stack has to do.
For publishers with more complex monetisation models, that creates a different question: how much of the infrastructure do they actually need to control?
Owning your infrastructure does not mean building it
Ownership means operational, product and commercial control, not always making back-end changes yourself.
Ozone is a useful example because its members hold the control that matters without each having built the infrastructure that delivers it. Ozone is owned by a group of UK national publishers, including News UK, Guardian Media Group, Telegraph Media Group, and Reach. Its members set the rules, hold the audience data, and decide which buyers get access. They did not each build individual, owned stacks. Instead, they created one shared platform, built to a specification they set together. In August, Ozone partnered with Content Ignite, whose technology is used by more than 400 publishers, to extend access to Ozone’s demand and Prebid server capabilities.
Ownership has two halves.
The first is commercial control: your auction rules, your floor logic, your demand relationships, and your decision about who can buy.
The second is platform control: the ability to change the infrastructure at the code level when the business requires it.
A publisher with control over both halves owns its stack.
Year one is a project; year two is a salary line
The business case for building in-house covers design, development, integration, and launch. It is one number, it has an end date, and it's a reasonably predictable estimate.
However, maintenance costs are far harder to predict. Standards change, and every integration has to be updated and retested. Video and audio players behave differently across versions and devices, so support efforts never end. Buyers cap how many requests they accept and throttle publishers who send too many, so keeping request volume efficient is constant work.
It is also a staffing question. Anything in the revenue path needs reliable on-call coverage, which turns a development project into an ongoing engineering commitment. A project becomes a permanent line item in the salary budget, and the work it puts on the back burner is usually what led to the decision to own the stack in the first place.
Some vendors sell a product; others sell a capability
Technology vendors do not all work the same way. Some sell a finished product, where the core auction logic and product roadmap remain largely standardised and improvements arrive when they reach the top of the vendor's list.
Others sell the infrastructure along with an engineering team that customises the platform to the publisher's specifications, so the auction logic, integrations, and reporting can change when the publisher needs them to.
Both models are forms of buying technology, but they leave the publisher with very different levels of control.
One pattern I have seen in our work with publishers is that the initial question is often framed as build versus buy. A year later, the more useful question is which parts of the stack actually create competitive advantage and therefore need to remain under the publisher's control.
Usually, that's audience data, deal logic, and pricing. Publishers should prioritise control over the infrastructure underneath, not the job of building it.
Five questions before the money is approved
Who owns this in year three, by name, and what happens when that person leaves?
When the IAB Tech Lab specifications we depend on change, who updates our integrations, and how quickly?
If this goes down on a Friday afternoon, who is on call, and are we carrying that team all year or only paying for it when we need it?
Are there more important strategic tasks for our engineering team than keeping this running?
Can we change the auction logic, retain full control of our data, and preserve those rights if we change providers?
Question five is the ownership test. A provider that cannot answer it clearly is selling access rather than ownership.
What ownership actually means
Ownership is control in two places. The first is the commercial layer, so the auction, the data, and the buyer relationships answer to the publisher. The second is the infrastructure, so it can be changed to fit how the business actually works. Who wrote the first version of the code matters less than the rights and control the publisher retains.
Both halves can be written into a business case and into a contract, which makes this one of the few transformation decisions a publisher can get right on paper before anything is built.
Publishers who secure both get a stack that is genuinely theirs. Publishers who focus on only one or the other risk remaining dependent on someone else's roadmap and commercial terms.