The Future of Sportsbook Technology: How Product Innovation Is Shaping the iGaming Experience
Ilija Micunovic is a Senior Product Owner at Sportserve, where he leads product for the sportsbook web frontend. With more than 15 years in the iGaming industry, he has worked across the full lifecycle of sportsbook products, from data integration to the player-facing experience. In this Expert Insights article, he discusses how real-time data, operator and player needs, data feed reliability, risk management and agile delivery are shaping the future of sportsbook technology.
Q: Based on your experience as a Product Owner, which key tech innovations (e.g., real-time data, micro-betting, personalization) are shaping the modern iGaming user experience the most?
For me it’s real-time data, and specifically latency, even though that’s the least glamorous part of it. Real-time data is what turned in-play into the main product, and micro-betting only works if the price on screen keeps up with what the user is watching. If the feed is a few seconds behind the stream, you can’t really offer a next-point market. Or you can, but you’ll regret it.
The part people underestimate is how much of this lands on the frontend. When a price changes while someone is building a bet slip, users are surprisingly tolerant of the move itself and much less tolerant of not understanding what just happened to their slip. I’ve seen small changes in how a price update is shown, a clearer indicator, a layout that doesn’t jump, lift bet placement more than some much bigger features.
With personalization, sorting sports and competitions has long been the basic level. Where I see the next step is inside the event: which markets appear at the top of the page, based on how that person actually bets. The harder question is where to stop, because personalization that nudges people to bet more is something regulators are paying more and more attention to.
Q: How do product development priorities differ when balancing operator requirements (B2B) against end-user expectations (B2C)?
On a platform you effectively have two customers, and their priorities are genuinely different. For operators, it’s control and predictability: market coverage, settings per jurisdiction, reporting, their own branding, and releases they can plan around, because nobody wants a surprise change on a busy weekend. For players, it’s speed and clarity: finding the event quickly, placing a bet in as few steps as possible, and understanding what’s happening on their slip.
Those two lists collide regularly. I’ve sat through a lot of prioritization discussions where both sides were completely right. The operator needed a configuration option for a regulatory reason, and from the player’s side it added one more thing on the screen. What I try to do in those cases is separate what has to be possible from what everyone sees by default. The option exists and the operator can use it, but the default screen stays as clean as we can keep it. That’s also what lets operators go live in a new market quickly, because the flexibility is already part of the platform instead of something built again for every launch.
It sounds simple, but most of the work is deciding what that default should be, because most players never change it. For them, the default is the product. When it’s right, operators get their flexibility and players never pay for it.
Q: What are the biggest technical challenges when integrating third-party API data feeds, and how do you ensure system stability during peak traffic?
The API itself is usually the easy part of integrating a new feed. The hard part is translation. Every provider describes the same match in its own way: different market names, different ways of counting periods, different rules for when a market settles. Before anything appears on screen, all of that has to be mapped onto your own model, and the cases that hurt are the ones that look identical but aren’t, such as two markets with the same name and different settlement rules. Get that wrong and you either settle bets on the wrong outcome or have to void them, and both cost money and trust.
The integration also doesn’t end at go-live. Data structures change over time, and a feed can be technically up while sending stale prices. So we validate incoming data before it reaches the screen and watch how fresh it is, since a connected feed can still be useless.
Peak traffic makes all of this harder, because a big final is when the feed sends the most updates and the most people are on the page. More servers help, but only so far. My approach is to decide in advance which parts of the page must stay real-time, like main-market prices and the bet slip, and which can refresh a bit slower under load, like statistics. Making that call two weeks before kickoff is a lot easier than making it during the match.
Q: How are modern tech tools empowering trading teams to manage risk effectively without disrupting the player journey?
For a long time, most risk tools were blunt, and the player felt every one of them. A market would get suspended or a stake limit cut, and from the customer’s side it simply looked like the site wasn’t working.
A lot of that has moved out of sight. Automated pricing covers most of the offer now, so traders can spend their time on the unusual cases. The controls are also much more precise: limits per customer instead of per market, a single selection suspended without pulling the whole event, and an in-play acceptance delay that depends on how risky the moment is.
Where it still reaches the player is when a bet gets rejected or a price changes at the last second, and I’ve spent more time than I expected on how the site explains those moments. A generic “bet not accepted” leaves the user guessing, and most will assume the worst. Telling them what actually happened, keeping their selection on the slip and offering the new price with one tap turns the same rejection into a minor delay. Letting players decide upfront whether price changes are accepted automatically helps too. A perfectly reasonable risk decision can look unfair if the message is vague, and that impression outlasts the bet, which is why I treat it as a retention problem as much as a UX one.
Q: Where is Sportsbook technology heading in the next 3–5 years, and how do agile project management practices help bring these innovations to market faster?
Video and betting will merge into one experience. Today they mostly sit side by side, and the next step is placing bets directly from the stream, which puts pressure on keeping video and data in sync. Once users bet on exactly what they’re watching, every delay between the two is visible. I also expect pricing automation to reach much further into lower-tier competitions, where there often isn’t enough data today. That’s where I think AI will make the biggest difference in the near term, in the back office more than in anything customers see. Safer gambling tools will move into the main flow of the product too, partly because regulators are asking for it and partly because that’s where they actually work.
On agile, the ceremonies are useful, but the real speed comes from releasing small changes often, to part of the audience, and seeing how people actually use them. Betting from the stream is a good example: nobody knows the right design upfront, and the way to find it is to put an early version in front of a small group of users and watch what they do. Some of the best decisions I’ve made came from exactly that. Some of the worst came from waiting until something was perfect.
