The engineer behind TeqBlaze: CTO Vlad Isaiko on architecture, R&D, and AdTech decisions

Vlad Isaiko has been shaping TeqBlaze's technical direction for more than a decade — long enough to watch the AdTech landscape change around him several times over. In that time, he's made the core architectural decisions behind the company's white-label technologies and AI tools. Beyond the architecture, he has also played a direct role in forming TeqBlaze's technical teams and developing engineers who understand AdTech from the infrastructure level up. One of those teams is R&D — a dedicated research function focused on emerging protocols, automation, and technologies that may later be incorporated into client platforms.

We sat down with Vlad to understand how he thinks, builds, and stays ahead of the market. It's part of a broader leadership picture we've been building out on the blog: CPO Olga Zharuk on long-term product thinking, and CDO Illia Ponomarenko on how client-facing teams operate day to day.

***

Grigoriy: Vlad, thank you for agreeing to this interview. Let’s start with a question about AdTech: why did you choose this particular niche? What attracted you to it?

Vlad: The tasks here are interesting and varied. AdTech combines high-load systems, big data, machine learning, artificial intelligence, and custom development across a wide range of complexity. The industry also isn't conservative — standards evolve, and new technologies emerge fast. You need to respond dynamically to market changes. Those are exactly the kinds of technical challenges I enjoy solving.

You are responsible for the development of TeqBlaze's technologies and lead the company's R&D department. What is taking up most of your attention today?

My attention is distributed almost equally across several areas. That includes improving existing solutions, driving R&D hypothesis work, and evaluating active projects with their KPIs. The rest is day-to-day work with the teams. AI process automation is also in active focus right now — and not just within our technologies. I mean company-wide processes.

As Chief Technology Officer, you're constantly balancing short-term business priorities with long-term technical sustainability. How do you approach that trade-off?

Every day for me is a compromise between technical accuracy and business demands. In the long run, though, we always ensure technical quality keeps pace with business-driven decisions. 

When the client brings a request backed by a real business opportunity, the outcome depends on the speed of our technical implementation. In such cases, we set aside our tech perfectionism in favor of a fast yet stable result. This is one side of the compromise we’re making, because we’ll definitely have the opportunity to refine this in the future. 

Over time, custom requirements and market-driven changes accumulate across the technology stack, and the architecture has to absorb them. At some point, when I realize the accumulated additions have become too heavy, we step back and rewrite the architecture from the ground up.

The goal of rewriting the architecture is to make all key additions part of the foundation. If we don’t have this done, in 2–3 years, we might not be as effective as we are now. Over the past 10 years, our technologies have undergone four full architectural rewrites. The goal is simple: rebuild the foundation before accumulated complexity begins to limit future development. Each rewrite takes months, but allows the technology to continue scaling without becoming a constraint for clients.

Which of the four technology rewrites was the most difficult, and why?

All four were difficult in their own way — and not because of the coding itself. The hardest part of any architecture rewrite is gathering business requirements for the new structure. That takes time from the entire company — both the technical and business sides need to align on what the new foundation actually needs to support. It also includes anticipating future needs, which matters just as much for the technology's long-term effectiveness.

Once requirements are finalized, neither coding nor testing is the hard part — that's actually interesting and meticulous work. But the beginning and the end are still not easy. Usually, the first 10% of the work requires more effort, and the last 10% requires even more effort. By the final stretch, you usually see a better way to do something — and that means going back to refine the architecture again.

After more than 10 years of working on TeqBlaze technologies, which architectural decision do you consider the most important? Conversely, which architectural decision would you definitely not repeat today?

The market and the demands around it keep changing, so naturally our technologies need modernization and rewrites — like anything else in this space. But I can't point to a decision I'd call a mistake. We've worked carefully enough that nothing stands out as something we regret.

As for the most effective move — one I'm quite proud of — it was building our own technological solution for processing trading data. Most standard approaches for transferring, storing, and processing this kind of data require costly setups with additional servers. That cost might eventually be passed on to our clients. So, we built a solution that fully meets our clients' reporting needs. It requires no additional servers or maintenance. It keeps running without data loss, with delays kept to the minimum allowed by the network, even during signal interruptions or technical errors. That held true even when major cloud outages hit, or the Red Sea internet cables were damaged.

How do new directions emerge at TeqBlaze — what triggers the decision to explore something new?

There are three main sources. The first is our own market monitoring — tracking where the industry is moving and what's gaining traction across players. The second is direct involvement in shaping how the industry operates. Our participation in IAB Tech Lab and Prebid working groups gives us a seat at the table where discussions shape new standards that everyone eventually builds on. The third is client feedback — we stay close to what partners actually need day to day, which keeps the technology grounded in real-world use cases. 

You mentioned market trend analysis as one of the sources. How do you decide what actually deserves attention — and what's just noise? 

I have three clear criteria: does anyone actually need it? Is there a clear path to implementation? Is it gaining traction with major industry players? If two out of three apply, that's a good signal; if all three, it's a definite yes.

Google's Privacy Sandbox is a good example of where this breaks down. The need was there — third-party cookies were being phased out, and the industry needed an alternative. But the path to adoption stayed unclear and complex for years. That uncertainty is exactly what signals a technology isn't ready, no matter how strong the underlying idea is.

Not every R&D hypothesis makes it into the core technology. When you have two equally promising ones that solve the same problem, what criteria do you use to choose between them?

In practice, we try to avoid this situation entirely — but if it happens, we choose the hypothesis that is easier and faster to implement, and that makes the most practical sense. 

How do you know when it's time to stop the research?

When we can determine the statistical or mathematical effectiveness of a hypothesis, that becomes the deciding factor — we either develop it further or shut it down.

Can you give an example of a hypothesis that seemed completely logical — but turned out to be wrong? 

Traffic shaping is a good example. Our solution sits on the SSP side and filters bid requests before they are sent to DSPs — reducing unnecessary bid traffic. At some point, we hypothesized that adding more parameters to our evaluation model would improve filtering accuracy.

We tested various additional parameters from the bid request fields as part of the traffic-shaping evaluation logic. It turned out that specific parameters introduced statistical noise. The model became more complex but less accurate — extra data was confusing it. We tested this mathematically, confirmed the effect, and removed those parameters from the model.

The takeaway: in dynamic systems, more input doesn't automatically mean better output. Sometimes a simpler model outperforms a complex one — and you only find that out by testing.

That's a case of a hypothesis that didn't survive testing. But have there been situations where TeqBlaze made a broader decision — to step back from an entire technology direction entirely?

Yes. The broad principle: when we can't create a clean, predictable solution that works reliably and can be fully supported, it's not worth the effort.

For example, we had the idea of developing a video player that publishers using our clients' platforms could use. The challenge is that a video player needs to work consistently across hundreds of different publisher websites simultaneously — each with its own technical setup. In practice, something that works perfectly on a hundred sites will inevitably break on the hundred-and-first, and the problem always turns out to be specific to that particular site. So, we abandoned that idea. 

With so many new technologies and trends appearing in this space, how do you avoid getting pulled into every one that looks promising?

The environment is too dynamic to pick a few directions and ignore the rest. Instead of choosing what not to invest in, we invest a little in almost everything reasonable — enough to understand what's there and how it could strengthen what we've already built.

That kind of flexibility doesn't happen by itself. In your view, how is the company structured to support it? 

We work across three layers, each built for a different kind of work. Client-focused engineering squads handle custom development tied to specific partner needs. Product teams own the core technology stack, driving ongoing development for everyone running on it. The R&D team deals with what doesn't exist yet, exploring new standards and protocols, testing hypotheses, building AI systems, and enhancing ready-made solutions in unconventional ways.

Together, these layers cover three things at once. Clients get fast, focused support on their specific setup. The core technology continues to evolve without disruption. And the company isn't caught off guard when something new becomes relevant.

And how do you keep that structure capable of staying flexible — reacting quickly when something new comes up? 

That's actually a bigger question than just engineering — it touches business processes, product, really the whole company. I can speak to the technical side, but for the full picture, you'd probably need the entire C-level in this room.

On the technical side, the core principle is that every team needs visibility into two things simultaneously: what clients need right now, and what the market is moving toward. If a team only sees current client tasks, it loses the ability to anticipate. If it only tracks external trends, it drifts away from what's actually relevant to the business.

For the R&D team specifically, priorities are reviewed regularly based on urgency, feasibility, and market relevance. That structure enables the team to move quickly and avoid being reactive.

Speaking of managing technical teams, how has your approach changed over the past 10 years?

I’ve learned to better recognize people’s strengths and work around their weaker areas. Annual reviews back that up. I'd say my biggest achievement as a leader is learning to match people with work that fits how they naturally operate. Some people do their best work on big, complex tasks that take weeks to complete. Others thrive on a steady stream of smaller, fast-turnaround tasks. 

One thing hasn't changed in ten years: anyone at the company can write to me directly if they're stuck on a problem. I still make a point of staying reachable — I regularly travel between our offices across different cities and spend time with people in person, not just over Slack.

In your experience, what separates a strong engineer from a good one?

What makes engineers exceptional isn't deep expertise in one area — it's the ability to switch between different tasks without losing quality or speed. A good engineer solves the problem at hand. A strong engineer can step into a completely different context, understand it quickly, and deliver.

Let’s move from team leadership to the broader AdTech market. What do most AdTech companies underestimate today in terms of technologies?

First, integration with any supply or demand source rarely works correctly by default. That's something the industry still underestimates, even when documentation is detailed and precise. We always set aside time for troubleshooting integration issues because skipping that step leads to unnecessary frustration and delays later.

The second point follows directly from the first: how inconsistently different platforms interpret the same data. No two ad platforms read the OpenRTB standard exactly the same way. There are dozens of companies that have been sending incorrect data in request fields for years — we build custom modules to automatically correct it. Another example: a publisher’s ad request states that the placement supports VAST versions 2.0 and 3.0, but the actual video player supports every version up to 4.3. By correcting that input on the publisher’s behalf, we unlock monetization potential they didn’t even know they had — without adding any false information.

Looking at the next 2–3 years of programmatic development, what would you identify as the technological foundation that won’t change?

OpenRTB will remain relevant even as more budgets shift toward alternative transaction models. I first heard about the "death of OpenRTB" more than 10 years ago, but in reality, I can see scenarios where this market's volume rises again. For example, when technology allows publishers to clearly track how much they are losing from reselling and which monetization paths are available to them.

How important do you think it is for AdTech companies to build their own AI tools — rather than relying on what's already available on the market? 

Very important — but not for the sake of AI itself. The starting point must always be a real business need. Both of our AI directions came from exactly that.

TeqMate AI started as a way to reduce manual investigation in AdOps troubleshooting. The first version was helping teams pull context from internal documentation instead of digging through it by hand. It's grown into a multi-agent system that retrieves operational context, detects anomalies, analyzes root causes, and independently validates decisions. For example, daily performance checks have been reduced from a couple of hours of manually reviewing dashboards to a ten-minute conversation with TeqMate. Setup validation has become even faster — it now happens in real time rather than requiring manual review.

The AdCP Sales Agent MVP is our way of working with where the market is actually heading. Buyer and seller agents are becoming part of how non-programmatic deals get negotiated, and we provide a ready-made solution so our clients can be part of this shift. Publishers running these deals manually have no standardized workflow today — just case-by-case negotiation. The MVP automates the operational side of the process, while the decision-making remains with the inventory owner.

Which of these market trends does TeqBlaze consider most relevant right now, and how are they directly shaping the tech roadmap?

Agent-to-agent trading is the one we're actively investing in. It's not just about bid requests getting larger and more expensive to process, though that's part of it. It's also about the broader shift toward LLMs and AI agents, and the real need of buyers and sellers to reduce manual work.

Right now, the practical use cases are things like automating direct deals, deal negotiation, inventory discovery, and campaign planning — not replacing open auctions at RTB scale. Agentic AI in AdTech is still early, and AdCP is one path forward. If it doesn't become dominant, more conservative approaches like ARTF and OpenDirect could gain ground instead. We're investing across all of them rather than betting on one.

Zero-click search is a different kind of trend. We're not investing in it directly, but we're watching it closely because it directly affects how much inventory publishers have to offer for trading. As AI-generated answers reduce publisher traffic, that's less inventory for everyone downstream. LLM search optimization is becoming part of how publishers need to think about their traffic, and we factor that into our advice on long-term monetization strategy.

And finally, what advice would you give to companies looking to develop their own programmatic platform?

Start with the business model, not the tech. Define what you're actually building toward, and check whether there's real market demand for it — plenty of platforms get built before anyone confirms someone needs them.

From there, figure out what genuinely needs to be built in-house versus what you can buy or license. Most companies overestimate the first category. Once that’s clear, build a realistic roadmap and bring in people with actual AdTech and programmatic experience early — back-end developers, salespeople with industry recognition, and account managers who’ve handled platform setups before. Skipping that experience is the most expensive mistake companies make; you end up paying to repeat problems someone else already solved years ago.

And you don't actually have to build from scratch. White-label technology already solves the technical side. Come to us, and you can spend that time and budget on growing the business instead.

***

Vlad has been making architectural decisions at TeqBlaze for ten years — and he's still the one making them today. That continuity shows up directly in how the technology evolves: steadily, with one consistent logic behind it. Part of that logic is a dedicated R&D function. Not every AdTech company has one — we do, and treat it as a long-term infrastructure investment. For any company serious about staying relevant, that's worth considering.

One thing that stands out from this conversation: knowing what not to build is treated as seriously as knowing what to build. Every rejected hypothesis and abandoned direction becomes the foundation for better decisions.