GR8 Tech Q&A: What platform providers can gain and risk from moving to Qwik

Why did GR8 Tech decide to move from React to Qwik, and what were the biggest problems with the previous infrastructure that you wanted to solve?

Initially, the problem wasn’t React itself. The reason we decided to refresh the frontend was that the original application had been written in React more than 12 years ago, so naturally there was a lot of legacy and redundant code and we needed to rewrite it anyway. It was also built with client-side rendering. For the last five or six years, server-side rendering, or at least a hybrid approach, has become a standard because it’s faster, more lightweight and gives users a faster interface.

So once we decided to rewrite it, the question was: if not React, then what? We looked at several options, including Next.js, Qwik, Svelte, and others. The two main candidates were Next.js and Qwik. What we realised was that Qwik was bleeding-edge technology, but it was also showing the most promising results for the future. Qwik is one of the fastest frameworks on the market, but of course that comes with risk. At the time, no large enterprise had adopted it for a project of this scale, and I believe we were the first. We even had support from Qwik’s core contributors along the way.

Being first meant we faced issues ourselves. With something like Next.js, there’s a huge community and most problems have already been documented. With Qwik, you often have to find the answers yourself. At the end of the day, we are an iGaming company, so this high-risk, high-reward approach is our motto. It doesn’t mean leaving the outcome to luck, but rather understanding the risks, preparing for them and making a deliberate decision when you know your team has the expertise to execute it. We understood the risk, but we wanted to go for the fastest technology on the market.

How did you benchmark the reported Speed Index of 1.72 seconds and Lighthouse scores of 90–95 against industry averages, including what devices, connection speeds, locations and testing methodology were used?

For our own metrics, we use real user metrics. Today, it’s mainly Chrome that allows us to get metrics like Speed Index, FCP, and LCP directly from users' devices. When the website loads, we can gather statistics on how long it takes to open on a user’s mobile phone or computer.

For us, the most important benchmark is ourselves. We compare our current performance to our previous performance using this real-user data because we believe it’s the most accurate way to measure it.

For competitors, we used several external services. One we used most often was Catchpoint, which lets you test websites using emulated devices from different regions. So we could compare our performance with competitors across different devices and locations. We also used some other services, but for our go-to internal metrics, we rely primarily on real-user data.

For someone who isn't a developer, what does the migration from React to Qwik actually change about the way the GR8 Tech platform works?

It’s getting much faster, around four to five times faster. That’s the main result we’ve seen. It also becomes interactive much faster. So as soon as something starts loading, you can click a button even if the rest of the website is still loading, and it will respond accordingly.

For someone who isn’t a developer, that’s really the main thing. We were doing this mostly for speed. But during the refactoring, we also significantly improved the system, removed redundant code and enhanced animations and the overall look and feel. So all in all, it becomes lighter, faster and smoother.

Beyond faster load times, what should operators expect this migration to change? Could it have a measurable impact on conversion, player retention or betting activity?

We definitely expect all that. We’re already gathering before-and-after data from a couple of brands we’ve migrated, and we’re seeing positive results. Until the end of the year, we’ll be heavily investing in data and continuing to optimise how we work with Qwik. We’ve only just gone into production, so we need more time to understand what we can improve.

Speed by itself can have a big impact. For organic traffic, for example, platform load speed is very important because Google takes website performance into account when ranking pages. It can also affect betting activity. If the platform is much faster, players can move through it and place bets more quickly. And of course, that also improves the overall experience and retention; if the platform is reliable, fast and easy to use, players are more likely to stay.

Were there any other areas you focused on as part of the overall technology upgrade?

Since we were reworking the architecture anyway, we took the opportunity to rethink the infrastructure around it as well: how to move the application closer to users, optimise network traffic, improve our CDN capabilities and prepare for future AI features.

For example, we also moved from standard CDN providers like Cloudflare to a custom setup, and we’re seeing around a 30% improvement on the network side alone.  The broader infrastructure work gives us a better foundation for adding AI and personalisation capabilities.

What's the one thing about this change that you're most excited to see in action?

I really want to see us become the fastest platform in the world and be recognised as such. That’s the main goal of this project – to have the fastest platform on the market.

We already outpace the typical B2B platform in speed. By the end of the year, we also expect to close the gap with in-house builds – those that traditionally have had an edge because they’re designed around a single operator's needs. At that point, even operators with the resources to develop proprietary tech would have a hard time justifying the effort.

We’ve completed the initial phase and moved to Qwik, but we now see plenty of areas for improvement: on the infrastructure and network sides, in caching and in how Qwik operates under the hood. Even as we speak, we’re working on a major release that we expect could improve performance by another 10%. So there’s still plenty of work to do, but I expect we’ll be even better by the end of the year.

If we speak a year from now, what would you hope to have achieved with the update that isn't possible today?

I think the biggest challenge we had, and still have, is when old and new components are on the same page. They’re not synchronised, so they can load at different speeds, and the old components can take much longer.

Our initial idea was to roll out Qwik component by component. For example, update only the header and push it to production, while everything else stays on the old platform. Technically, it works, but the user experience can be degraded, so we decided to postpone some releases and complete more of the platform in Qwik before rolling them out. That’s something I’d really like to see improve over the next year, because it would give both Qwik and us much more flexibility in development and allow us to release changes more gradually.

It would also make it easier for our clients’ technical teams to contribute. Today, clients can add their own code, widgets or front-end components, but ideally, they shouldn’t need to become Qwik experts. They may prefer to work in React, and we want to make sure that they can work smoothly alongside Qwik.