Build vs. Buy in AdTech: A Conversation on Custom Platform Development, Telcos, and the Cookieless Shift

Building a high-performance platform for buying and selling digital media — or reporting on campaign performance, or assembling audiences from first-party data — requires a very specific combination of skills, domain knowledge, and engineering experience. Finding people who have all three is genuinely difficult.

The following is an edited transcript of a video interview exploring which types of companies are investing in custom AdTech and MarTech development, why many are choosing to build rather than buy or acquire, and what makes these projects particularly complex.

Which types of companies are investing in custom AdTech development?

The range is broader than most people assume. It's not just established AdTech and MarTech vendors looking to extend an existing DSP, SSP, or data platform. Publishers — large ones especially — are in the mix, as are media agencies. And then there are the less obvious verticals: retail media is extremely active right now, the telco industry has been wrestling with advertising technology for years, and even banking and financial services companies are increasingly looking at what marketing technology can do for them.

What these companies share isn't a vertical — it's the desire to participate in programmatic advertising in a serious, infrastructure-level way.

What's driving new entrants from telco, retail, and banking?

The pattern in retail media and telecommunications is similar: these are companies sitting on significant first-party data assets or owned ad inventory, and they're asking whether the scale they operate at justifies building proprietary technology rather than renting it from a third party.

The cookieless transition has accelerated this. As the third-party cookie infrastructure that underpinned much of programmatic advertising becomes unreliable, companies with strong first-party data positions are looking at building their own identity and targeting infrastructure. In the European telco market in particular, there's been real momentum around unified user identification — and that creates direct demand for custom advertising technology.

The challenge for many of these companies is that they already have complex existing ecosystems. Adding a third-party white-label platform on top of that complexity is often harder than it sounds, and the integration friction creates a genuine case for building something purpose-built.

Why build custom software rather than rent or acquire an existing platform?

There are two main economic arguments for building custom AdTech.

The first is cost at scale. Third-party white-label and SaaS AdTech providers typically charge based on traffic volume — a monthly or yearly fee tied to how much the platform is used. When a company's scale is large enough, the ongoing licensing cost eventually exceeds what it would cost to develop and maintain a proprietary system. At that point, cutting out the intermediary and owning the infrastructure outright starts to make financial sense, with the main ongoing costs being development and cloud infrastructure (AWS, Azure, GCP, or whichever provider fits the architecture).

The second argument is data ownership and privacy. Using a third-party provider means sharing data with that provider. For companies that consider their first-party data a core strategic asset — and are increasingly cautious about where it flows — that's a significant concern. The pushback against white-label solutions is often rooted here rather than in cost.

These two factors together — economics and data control — tend to frame the build-versus-buy conversation at the start of most custom AdTech engagements.

What about acquisition rather than building from scratch?

Acquisition looks attractive on paper: you get a working system, existing integrations, sometimes an existing customer base. But the technical reality is often harder than anticipated.

The AdTech industry has seen a lot of consolidation. AT&T's acquisition of AppNexus — which was subsequently rebranded as Xandr and later acquired by Microsoft — is probably the most prominent example. But across the telco sector more broadly, the story has repeated: a carrier acquires an AdTech platform, struggles to integrate it into an existing business ecosystem built for a completely different purpose, and eventually divests at a loss.

The core problem is that acquired systems are built to a different architecture, at a different scale, with different assumptions baked in. Adjusting them to fit the acquirer's ecosystem often requires significant rewriting anyway — which raises the obvious question of whether the acquisition was worth it in the first place. In many cases, companies that initially explored acquisition have ended up concluding that a custom build was the better path.

How is the super-app approach different from the telco approach?

It's a meaningful contrast. Where telcos largely went down the acquisition route, companies like Uber, Instacart, and DoorDash have been building advertising technology in-house. The reason isn't hard to understand: these platforms already have rich, first-party behavioural data on their users, and that data is the core asset of any AdTech system. They're not trying to graft an AdTech capability onto a business where it's peripheral — advertising is a natural extension of what they already know about their users. Building proprietary systems to exploit that data advantage makes straightforward strategic sense.

Whether those in-house builds will outperform what telcos attempted through acquisition is still playing out, but the early structural logic is stronger.

What makes custom AdTech development genuinely difficult?

Domain expertise is the central issue. AdTech is a field with a dense vocabulary — DSPs, SSPs, CDPs, QPS, bid requests, OpenRTB — and that vocabulary maps to real architectural and protocol-level requirements that experienced software developers without AdTech background will struggle with.

A DSP, for example, requires understanding the OpenRTB protocol, what a bid request contains, and how quickly a bidder must respond. Those constraints shape the entire system architecture. A developer unfamiliar with the domain doesn't just face a learning curve — they face a situation where they may not even know what questions to ask.

There's also a definitional challenge. Companies often come in saying they want to build a specific type of platform, but when requirements are explored in depth, the actual business need sometimes points to a different system entirely. "I want a DSP" occasionally turns out to mean something closer to an analytics layer, or a CDP, or a custom yield management tool. Working through the discovery phase carefully — mapping business requirements to the right technical architecture — is as important as the engineering work that follows.

High-scalability requirements add another layer. Platforms handling large volumes of bid requests or complex real-time data operations require specific engineering experience. Companies that have tried to build these systems internally without that background, and later handed the project to specialists, often describe the internal attempt as a costly detour rather than a foundation to build on.

What does good strategy look like before building?

The technical build is the end goal, but a discovery and strategy phase is what makes it achievable. Companies entering the AdTech space — particularly from retail, telco, or other non-native verticals — often have sophisticated business goals but need help translating those goals into a coherent platform architecture and build roadmap.

The business logic belongs to the company building the platform. The translation from business logic into AdTech system design, integration requirements, and technical sequencing is where accumulated domain experience matters most. Getting that alignment right early prevents the expensive course-corrections that happen when complex builds are launched without it.