The World Cup is one of the largest global moments in sports, bringing together audiences across every time zone. During the tournament, user behaviour shifts in predictable and sometimes surprising ways. People check live scores more frequently than usual, follow specific teams and/or players with heightened attention, and consume far more highlights and sports-related content. In parallel, expectations also rise significantly — users expect real-time updates, easy navigation and uninterrupted performance, regardless of spikes in traffic or intensity of demand.
While this surge in activity is visible to end users only over a few intense weeks, the reality is that preparing for such moments is a long-running effort that begins months in advance. Behind the scenes, teams work through planning cycles, decision-making, technical preparation and iterative testing to ensure systems are ready for peak demand and rapid change. While fans see the tournament unfold on the pitch, technology teams have often already spent a considerable amount of time ensuring the user experience can keep pace with the moment.
Understanding the Challenge Before Writing Any Code
The 2026 FIFA World Cup is one of the largest tournaments in football history. 48 teams, 104 matches, hosted across three countries. For a technology organization like ours, that scale of demand, concentrated into a few weeks, with no margin for error, requires a high level of preparation.
We have been here before. Major sporting events are part of our rhythm: Cheltenham, the Grand National, Champions League finals... We know how to prepare for peak moments. The World Cup sits in a category of its own, though — not because the principles change, but because everything is amplified. The global interest, the time zone spread, the volume of simultaneous high-intent moments, all mean the strategic work starts long before any code is written.
That work begins with understanding how our market is evolving within today's football landscape, listening to how customers are engaging with our products and learning their expectations. Customers know what they want and they expect to get it instantly. Building for that means studying behaviour patterns across previous tournaments, understanding where friction appears, and designing experiences around how people actually use the product under pressure, not how we assume they do.
From that understanding, preparing for traffic becomes far more grounded. We cannot know exactly what a World Cup quarter final involving the home nation will do to our systems, but we can load test at realistic scales, model the scenarios most likely to create stress, and make sure our infrastructure can absorb demand that arrives suddenly and unevenly. Resilience is built into the plan from the start, giving us visibility and recovery capability when it matters most.
The harder conversation is always about what to build. Every major event brings new feature ambitions alongside existing reliability commitments. Balancing those priorities — deciding what is feasible, what is risky, and what should wait — is where strategic planning really raises its value. It is not a constraint on innovation; it is what makes innovation safe to ship.
The decisions made in that phase shape everything that follows.
That is where this story begins.
Turning Ideas into Deliverable Features
The preparation for the World Cup demands more than infrastructure and load testing; it demands clarity on what to build. Blip faced a crucial question: which features would deliver the most value, and which could wait?
Feature ideas don't emerge in isolation. Our approach combines multiple signals: direct customer feedback from previous tournaments, market observations about how betting patterns evolve, and learnings from past events.
During those events, we capture granular data on where customers encounter friction, which moments drive the highest engagement, and which expectations remain unmet. For the World Cup, the research phase focused on understanding not just what customers wanted, but when they wanted it and under what conditions they would be accessing the product.
Prioritization became the critical initial filter. Working across product, engineering, and business teams, we evaluated each feature against three dimensions: alignment with customer value (would this solve a real problem?), alignment with business goals (does this strengthen our position?), and feasibility within the compressed tournament timeline.
Turning priorities into delivery required close coordination across the business. Every feature became a thread woven through multiple teams, with cross-functional dependencies, shared goals, and careful alignment needed at every stage.
Risk management sat at the centre of this work. We used feature flags and canary deployments to roll out new capabilities gradually rather than through a single "big-bang" release, reducing the blast radius if something went wrong. Load testing simulated realistic World Cup scenarios to ensure our systems could withstand the levels of demand expected during the tournament.
The toughest decisions weren't about what to build, but what to leave out. Every team had ideas that could enhance the product, but the World Cup's compressed timeline demanded ruthless focus and clear scope.
What was decided during that planning phase shaped everything that followed.
That's where the real work began.
Engineering for Performance When It Matters Most
Every top athlete spends months, sometimes years, preparing for one moment. The training, the small adjustments, the countless repetitions. All of it builds toward a few weeks when everything has to work.
Engineering is not so different.
Throughout the year, our teams build, test, and ship features. Every release, every game, every regular event is a chance to validate what we produce. But there is always a moment that pulls everything together. Tournaments like the FIFA World Cup bring a different level of scrutiny. Alongside our regular customers comes a surge of occasional and first-time users, all expecting the same experience: fast, intuitive and reliable from the very first interaction.
That is the real challenge. Building something that impresses your most demanding users while still being effortless for someone opening the app for the first time.
We start planning for these moments well in advance, but plans meet reality, and reality is shaped by the business. Priorities shift, new requirements come up, and we are often challenged to adapt quickly. This is where agility really matters for us. It is a practice we rely on to move fast without losing confidence in what we ship.
Sometimes that agility means responding to what customers are telling us in real time. One example: in the run up to launching one of our World Cup features, we had originally planned to exclude a specific market offer from a certain category. Once the feature went live, we saw our customers clearly wanted access to it. So, we made the call to release it, right in the middle of a public holiday, expanding the offer to that category on the spot. That was only possible because we had a team ready and empowered to act, and it shows what it takes to support a fast, confident change in scope.
Other times, it means responding to the needs of the business itself. We have brought feature launches forward to meet a tighter time to market, something that only works when different areas of the business come together to shape the best possible plan.
To make that possible, we need a robust system, with clear processes and fast decision making, so we can deliver quickly without losing confidence in what we ship.
Testing Like the Stakes Are Real, Because They Are
Every major competition is prepared with a heavy round of load testing, run in close partnership with our Performance Services team. Together we adapt workflows and targets service by service, so the tests reflect what will actually happen on match day, not a generic worst case.
Every feature that gets launched goes through a rigorous pipeline of tests. We look at common paths, but also edge cases, the scenarios that rarely happen but can cause the most damage when they do.
Customers want new things. That is a given. But what matters even more is a fast, reliable experience where they always know exactly where they are and what to do next.
Think about the pace of a football match. Everything happens quickly, decisions are made in seconds, and the emotion builds in real time. The experience we offer has to keep up with that same rhythm. A slow product during a fast moment breaks the connection with the customer.
Beyond what we set out to cover, a few other practices matter just as much when the stakes are high.
- Observability and real time monitoring: During a major event, we are not just watching for outages. We rely on tools to track latency, error rates, and customer behaviour in real time, so we can react before small issues become big ones.
- Incident readiness: War rooms, clear on call rotations, and rehearsed response plans. When something goes wrong during a live match, there is no time to figure out who does what. That has to be decided in advance. For matches we consider higher risk or higher importance, we go further. We keep dedicated on call and active support teams watching in real time, ready to react the moment something looks off.
- Feature flags and progressive rollout: Being able to turn a feature on or off instantly, without a new deployment, gives us control when it matters most. If something behaves unexpectedly, we can pull it back in seconds.
- Capacity planning: We plan not only for the peak we expect, but also for scenarios beyond it. Building in headroom is part of how we prepare for the unexpected.
- Learning after the fact: Once the event is over, we conduct a structured review of what worked and what did not. These retrospectives feed directly into how we prepare for the next one.
Continuous Improvement Doesn't Stop at Kickoff
Anyone who has lived the tension of cheering for their team during a big match knows that feeling. The nerves before kickoff, the tension building with every minute, the relief when the final whistle blows in your favor.
At Blip, we don’t see the delivery of a new feature as the end of its lifecycle, but rather it's only a portion of the result.
Upon the delivery of a new feature, the Engineering teams continuously monitor its functioning and performance, both for issue prevention, but also for continuous learnings on what should be improved; this, along with the continuous experimentation and feedback by our Product teams, allows us to always keep the edge on everything we ship out.
During such a complex event as the World Cup, just being ready to respond to incidents isn’t enough, we strive for excellence, and this is achieved by having the right monitoring in place, but, most importantly, by having the right people always ready to respond even before the customer notices there is a problem.
Above all, we fully embrace the understanding that our job is an end-to-end affair, and it doesn’t just stop when the main event starts.
Looking Beyond the World Cup
A tournament like the FIFA World Cup is more than a test of technology. It's a test of how an organization works under pressure and it doesn’t move for anyone.
We went into it with a clear North star: restoring trust in the native experience. It was a measurable commitment shared across product, engineering, and design, against a deadline we could count in days.
One lesson stood out: a fixed deadline is a powerful decision-making tool.
To improve app performance, we focused on four major workstreams running in parallel: technical foundations, performance bottlenecks, core user journeys, enjoyable experiences. All four aimed to deliver not only a more reliable and solid experience to our customers but also the kind of polish that makes an app feel fresh and new, rather than just functional.
One of the earliest decisions we made was to treat performance as a key metric throughout the program and not something to validate at the end. Which sounds obvious. But rarely is in practice.
When we measure performance from the start, it changes how decisions get made in everything we do. Instead of building fast and optimize later, we’re building with a defined standard already in place as a condition to move forward. Especially on customer sentiment metrics where the voice of the customer is louder, these need to be daily conversations and not “optimizations for later”. There’s a real measured impact connected directly to what our customers experience.
Load times, rendering efficiency, stability under peak load — for an event where you are expecting traffic multiples of your normal peaks, that discipline compounds.
When it comes to AI, what we noticed is that the teams where it had the most impact were the ones with the most alignment: Clear problem. Clear user. Clear success criteria. In those conditions, AI did not just save time, it changed what was possible within the time we had. It compressed the distance between thinking and building in a way that felt genuinely different.
At the end, everyone knew the North star. Everyone knew the deadline. Everyone knew what the others were working on and why it mattered to what they were doing. That common context meant decisions could be made at the right level, without escalation, without bottlenecks. People could unblock each other because they understood the whole, not just their part.
Seventy-one days, with multiple workstreams running in parallel and what kept everything together was a deep understanding of the shared context, not a coherent process.
That kind of alignment does not happen by accident. It gets built deliberately, through the way information is shared, through the conversations that happen before work starts, through the discipline of making intent explicit rather than assumed.
Events like this have a way of revealing what an organization is truly capable of when every team, every discipline, and every workstream has to move together toward the same thing.
There will always be a next moment. We are already on our way to it.
The true achievement isn’t what we built, but how we became the organization, the team, that built it.
