Real-time virtual advertising platforms for sports leagues @ TGI Sport (formerly AIR, acquired by TGI Sport in 2024)

Full CV index — Tony Miasoedov

Context

TGI Sport and its division AIR do real-time virtual advertising. We work with the biggest sports leagues, federations and media platforms: Bundesliga, La Liga, NHL, UEFA, FIFA and others.

I was originally hired at AIR to build a SaaS platform for our clients. Its main job is to create playlists, manage ad campaigns and integrate with different media platforms in real time. It was a greenfield project where I was the tech lead, responsible for the architecture, development and rollout of key features. See Hub below.

In 2024 AIR was acquired by TGI Sport, a much bigger company that already had its own ad management platform. I joined the team developing it. See Vault below.

I work in English in an international team: sales in Germany and London, operators in the USA and Canada, a development team in India, and clients in Europe, Korea, the Americas and Australia.

Hub — greenfield SaaS (2023 — 2024)

The goal: build a fully functional end-to-end SaaS in 6 months. The deadline was very tight, because the sports season starts in September and the platform had to be fully ready by then. The requirements weren't defined yet — the project manager had joined only 2 months before me — so I drove discovery together with the stakeholders.

Technical requirements:

Team: a small team — me as the tech lead and senior developer, and a junior developer I led and mentored. A second web team supported the old hubs, whose clients were to move to our platform.

Stack: the whole system was built on AWS.

Vault — brownfield platform (2024 — present)

Vault is a large brownfield system developed by a team of 20 outsourced developers in India, with the PM in the USA. Before I joined, the platform had been developed for 6 years by the outsourced team alone. The biggest sports leagues already work on it: MLS, MLB, AFC (the Asian Cup organizer) and others.

I work on it as a Senior Fullstack Developer.

Stack: React, TypeScript, NestJS, AWS Lambda, AWS SQS, PostgreSQL.

What I did well — Hub

Organizing the work with rights holders

My strategy was maximum transparency:

Thanks to this approach, we could fix mistakes and add the features people needed at an early stage.

Brought QA into web development

I was the first to bring QA into our development process. Before that, the QA team tested only the Computer Vision software — and the hub's main job was to create playlists for that software. So the QA team started testing the hub too. They had a large collection of corrupted files and knew the real file sizes and counts, so we worked with real data from the start.

Automated testing

I set up unit and integration tests for all key components of the system. The junior developer hadn't worked with testing before, so I did the overall setup myself and taught them to write unit and integration tests.

I set up screenshot tests in Storybook. Our QA had access to Storybook and could test components, widgets and pages.

AI features in production

I shipped several AI features to production:

  1. AI tutorials in the client's language. Since we were building a new system, I created a FAQ section with videos showing the main processes. I learned to make tutorials like these as a freelancer on FL.ru and at Lovado. For this project I created my own AI avatar with HeyGen and voiced it in the clients' languages with my own cloned voice through the ElevenLabs API. A demo is in one of my LinkedIn posts: https://lnkd.in/p/dGn7A-xd
  2. A chat with RAG search over the knowledge base. Back when RAG was still new, I built a vector database with OpenAI embeddings, so a user could ask a question about the project and get relevant answers from the knowledge base.

After a client demo, the head of Sales wrote to me personally to thank me for the tutorials and the AI features. They especially impressed our colleagues from Italy and Korea: some Korean operators didn't speak English, and the tutorials and the search worked in their native language.

Passed clients' penetration tests

Many clients' contracts required penetration tests. They were run by the clients' security teams and by external auditors to make sure our system was reliable and secure. We passed all of them.

Results

We launched on time for the start of the season. The hub was presented to clients, and the leagues started testing it and rated it highly. But after the acquisition, the company decided not to develop it further, to avoid having 2 competing systems inside one product.

Today our QA engineers use the hub, because it is still the simplest and most convenient way to create playlists. They create playlists to load into our Computer Vision system.

What I did well — Vault

Mapped the whole system; the map became the basis of the due diligence

I was chosen as the only developer to go to India and analyze the existing architecture and development processes. I had earned that trust while building the hub: my technical knowledge was valued, and the company knew I took the work seriously. Before the trip I had already analyzed the Vault code and shown the PM the problem areas.

After the trip I drew a C4 model of the whole system, which became the basis of the due diligence process.

For the PM I highlighted the key points to watch in the further development of the platform, and I proposed improvements to the development process and to how the teams work together, to raise the efficiency and quality of the work on the platform.

What was done on my recommendations:

An AI agent for QA to tame 120+ feature flags

Vault serves very different sports and leagues. Every league has its own process, and Vault adapts to it: it doesn't build one shared happy path, but a separate path for each client.

We have 120+ features behind feature flags that are switched on individually for different clients. This gives flexible control over the platform's functionality, but it makes testing hell, because the flags can be on in any combination.

QA engineers test manually, and they often skipped building the full config and tested only partially, which led to many bugs after release to production.

Seeing this problem, I set up an AI agent for the QA team. It has read-only access to production and write access to the QA environment. QA engineers can ask it to create, say, the NBA config in the QA environment.

There is no exact metric — the evidence is empirical — but the number of bugs dropped noticeably, and so did the QA reaction time to incidents: they reproduce the problem environment in QA very quickly. What used to take several days now takes a few hours.

An AI agent that analyzes logs after incidents

The agent monitors errors. It has read-only access to the production logs, and also read-only access to the code repositories and the Lambda functions. Its job is to catch an incident and write 2 reports:

  1. A report for the PM and the clients explaining what happened — by contract we have to give them this information.
  2. An internal report for the development team, with the places in the code where the error happened and a proposed fix. Once a developer approves the fix, the agent fixes the error and opens a PR.

Before the agent, the PM pinged the whole team during incidents. These happened before games — on Friday nights — which pulled developers away and slowed down solving the problem. Now the agent pings only the responsible back-end or front-end developer, depending on the incident. A developer is still needed at that stage, because the agent has no rights to change the database or push to production.

Ownership of key components

I own key client-facing components of the platform end to end — development and support. For a SaaS platform, client features are the main competitive advantage, so their implementation details are under NDA.

Stack & skills

Full CV index — Tony Miasoedov