When does it make sense for a publisher to own an SSP? Insights from Mykyta Plastomak

In a recent LinkedIn discussion, Mykyta Plastomak explored why larger publishers are increasingly interested in owning more of their monetization infrastructure instead of relying entirely on third-party platforms. The natural next question is more practical: when does that ownership actually make business sense?

Launching your own SSP is not simply the next stage of growth for every publisher. The decision depends on the scale and economics of the existing monetization business, the inventory behind it, the demand relationships a publisher can maintain or build, and whether the team is ready to operate a platform rather than simply use one.

Mykyta has spent more than ten years in AdTech, working across operational, business, and sales roles, with publisher monetization remaining a recurring part of that work. We sat down with him to unpack what publishers should calculate and validate before moving from using third-party SSPs to operating their own infrastructure.

This interview is part of our ongoing TeqView series, where we talk to the people shaping TeqBlaze from the inside.

***

Grigoriy: What usually makes publishers seriously consider launching their own monetization infrastructure?

Mykyta: The first reason is economics. Once programmatic becomes a meaningful revenue stream, publishers start looking more closely at platform and intermediary fees and whether owning the technology layer could improve their margins.

The second is control over auction logic, integrations, monetization rules, reporting, and how the platform evolves around the business.

Transparency also matters. Some publishers want more direct relationships with DSPs, agencies, or other demand partners instead of relying entirely on demand available through existing SSPs. But owning an SSP does not automatically create demand. The technology enables direct integrations, while the publisher still has to build and maintain the commercial relationships.

Do you see this becoming a broader trend, with publishers moving toward their own infrastructure?

We increasingly see publishers and publisher networks evaluating this model, especially when advertising becomes a strategic revenue stream rather than an additional income source.

As programmatic revenue becomes more important, publishers look more closely at the economics of third-party infrastructure. Changing search behavior, AI interfaces, and less predictable traffic growth also make margin efficiency more important.

That does not mean declining traffic automatically makes owning an SSP more attractive. Scale still matters, but it increases the importance of understanding how much value is retained or lost across the monetization chain.

Speaking of inventory types, which publishers are the strongest candidates for launching their own SSP?

Inventory type or volume alone does not determine whether launching an SSP makes sense. I usually look at revenue first because it shows whether there is enough monetization activity for ownership to be worth evaluating. Then we look at inventory: volume, geography, formats, uniqueness, quality, supply stability, and the QPS required to monetize it. These factors affect both demand potential and operating cost.

So revenue tells you whether SSP ownership may be worth considering, while inventory tells you what it is likely to cost and how complex it will be to operate.

What ad revenue level makes launching your own SSP commercially viable?

From the cases we evaluate, around $100,000 in monthly programmatic revenue is a useful point at which it becomes worth running the calculation, but it is not a universal threshold.

A publisher at $80,000 can have a stronger business case than one at $150,000 depending on platform fees, traffic volume, infrastructure cost, demand relationships, formats, geography, and growth plans.

The number is really a signal to stop asking, “Are we big enough?” and start building an actual business case. Strategic needs such as custom formats, proprietary optimization, first-party data control, or plans to onboard additional publishers can strengthen that case.

How practical is onboarding other publishers into a broader supply network under a unified brand?

It is absolutely possible, but at that point the company moves beyond monetizing only its own inventory and starts operating a supply platform.

For example, a financial media company might start with its own properties and later onboard publishers from the same vertical, creating a differentiated supply package for buyers.

The model also becomes more complex. You need publisher contracts, onboarding, quality controls, billing, support, seller transparency, ads.txt and sellers.json management and, where relevant, schain. You also need people to acquire and manage that external supply, so include it in the business case from the start.

What team does a publisher need to run their own SSP, and what can the white-label vendor cover?

For a publisher monetizing its own inventory with a white-label technology partner, the minimum internal setup is usually an AdOps owner and someone responsible for commercial demand relationships.

AdOps operates the platform, monitors performance, handles configuration and optimization, and coordinates technical issues. The commercial person works with DSPs, agencies, networks, and other demand partners. If the company also wants to onboard external publishers, supply-side business development becomes another function. The white-label vendor can cover the core platform, maintenance, technical support, updates, and scalability, while the publisher focuses on operating and growing the business.

Let’s say a publisher is at the point where ownership looks realistic. What should they calculate before making the call?

Start with the current baseline: how much programmatic revenue are you generating, what are you paying in SSP or platform fees, and what margin could realistically be retained?

Then calculate the actual cost of ownership, including platform licensing, hosting and QPS-related infrastructure, internal AdOps and commercial FTE, integrations, support, compliance, legal work, billing, and any additional supply or demand costs.

Migration should also be included. Publishers need to account for gradually moving traffic, testing integrations, and allowing demand relationships to ramp.

Then model the upside conservatively: margin recapture, new demand integrations, direct deals, new formats or optimization logic, first-party data monetization, or third-party supply. Once you combine the baseline, costs, migration, and realistic incremental revenue, you can calculate the payback period.

Beyond retaining more revenue, where can the financial upside come from?

Margin retention is only one part of the business case. Ownership can also create revenue opportunities that are difficult to support through a standardized third-party platform, such as proprietary contextual targeting, differentiated inventory packages, specific demand integrations, custom formats, or controlled commercialization of first-party data.

How difficult is it to preserve existing demand partners when moving to your own platform?

You should not assume existing demand relationships will transfer automatically. Some partners may be straightforward to reconnect, while others may require new contracts, certification, endpoint testing, traffic validation, or different commercial terms.

That is why I strongly recommend a staged migration. Keep the existing setup running, connect demand to the new environment, test limited traffic, compare performance, and increase the share only when the numbers support it.

If a publisher currently monetizes through Prebid and GAM, how does launching their own SSP change that setup?

It does not mean replacing the existing stack. A publisher can keep parts of Prebid client-side, move selected integrations server-side, or operate a hybrid architecture depending on latency, QPS economics, formats, bidder support, and the existing setup.

Server-side infrastructure can make it easier to support more integrations, but QPS limits, bidder capacity, timeouts, infrastructure costs, and performance trade-offs still remain.

GAM can also remain the publisher’s ad server and decisioning layer. The owned SSP becomes another monetization component, giving the publisher more flexibility over how demand and infrastructure are connected.

Once a publisher launches their own platform, how hard is it to find and onboard new demand partners?

Publishers should validate this before launching, not after. Existing SSP and DSP relationships help, but knowing a partner does not automatically mean they will integrate directly with a new SSP endpoint.

Before committing to the platform, talk to the demand partners you want to keep or add. Ask about direct SSP integrations, commercial and technical requirements, expected volumes, formats, geographies, and onboarding timelines.

You do not need every possible demand source confirmed before launch, but you need enough validated demand to make the initial monetization model credible.

What are the most common mistakes publishers make when they launch their own SSP?

One of the biggest is treating deployment as the finish line. A platform can be technically live while demand still needs to be integrated, commercial relationships built, supply onboarded, reporting configured, compliance established, and teams trained.

Another mistake is launching before validating demand or underestimating operating costs, especially QPS, integrations, and internal team requirements. The companies that do best treat the SSP as a business function rather than simply a software deployment.

At TeqBlaze, how long does it typically take from the first conversation to a live platform?

There are two timelines to separate: the commercial and planning process, and the technical deployment itself.

Planning includes understanding the business model, agreeing on scope, confirming integrations, finalizing responsibilities, and signing the agreement. A white-label platform can then be deployed much faster than an SSP built from scratch, although timing still depends on scope, infrastructure, integrations, custom requirements, and team readiness.

A technically live platform is also not the same as a fully operating SSP business. Demand onboarding, compliance, seller transparency, billing, and gradual traffic ramp-up still need to happen afterward.

From a technical standpoint, how does a white-label platform differ from one built from scratch?

Both models can result in a branded SSP that the company operates as its own platform, but the ownership model differs. With a custom build, the company typically funds and owns the engineering work, codebase, infrastructure architecture, maintenance, roadmap, and ongoing development.

With white-label technology, the vendor provides the core platform, infrastructure, maintenance, updates, and scalability, while the publisher controls business configuration, integrations, monetization strategy, branding, and commercial relationships.

White-label can therefore reduce time to market, upfront development cost, and technical risk. The trade-off is that the core IP usually remains with the technology vendor.

What should a publisher calculate and validate before deciding whether platform ownership is the right move?

I would look at seven areas together rather than treating any single metric as a go/no-go decision: current monetization economics, inventory economics, supply strategy, demand readiness, internal team capacity, the current technology stack and migration path, and the full financial model.

That model should include licensing and infrastructure, internal FTE, integrations, compliance, migration cost, expected margin improvement, incremental revenue, and the resulting payback period.

If those pieces work together, platform ownership becomes a business case rather than simply an attractive technology project.

What advice would you give publishers considering their own SSP but still putting the decision off?

Do not launch because ownership sounds strategically attractive, but do not reject the idea simply because building an SSP from scratch looks too expensive or complex.

Run the numbers, validate demand, understand the operating model, use conservative assumptions, and test the technology before committing significant traffic.

If you choose a white-label technology partner, evaluate not only the product but also the team behind it: how they support integrations, handle infrastructure and scaling, respond when something goes wrong, and divide responsibilities after launch.

Sometimes the conclusion is that launching an SSP makes sense now; sometimes the right answer is to wait. The point is to make that decision based on a business case, not an assumption.

***

Want to understand whether the numbers work for your business? Talk to the TeqBlaze team about your SSP business case.