"CTO in Focus" Eduard Fumàs, Alea

Kevin Jones
2 days ago
5 min read

The gambling supply chain has a quiet technical debt problem. Platforms get built under commercial pressure, launched to meet client timelines, and then left largely untouched for years, not because the architecture ages well, but because reopening a system that still technically functions is rarely treated as a priority. Most supplier CTOs treat this as an operational fact of life rather than a strategic liability.

Alea's CTO describes what he frames as a deliberate departure from that default. Across this interview, he outlines a practice of continuous stack modernisation, recounts halting a game provider integration mid-delivery when technical risk surfaced, and explains a separation between core platform work, where he says release quality is tightly controlled, and internal tooling, where the team experiments at low cost.

Whether that discipline is structural or simply personal conviction is the question this conversation tests.

Gaming Eminence: Most CTOs can describe their responsibilities. Fewer can articulate the moments that changed how they lead. Which experiences in your career forced you to unlearn an instinct, habit, or belief about technology leadership and how does that show up today in the way you hire, delegate, or step in?

Eduard Fumàs: "Early in my career, my gut instinct was always to jump in and fix things myself. I assumed that, as a technical leader, this was my primary purpose. But I quickly realised that you don't build a company with just one or two people; you build it with teams.

As such, I had to learn how to delegate and embrace the fact that success is driven by the team taking the lead. A real leader isn’t there to just give orders or do the work; they are there to provide context, influence the direction, and light the path ahead. It’s always about the unit. I truly believe that letting people take ownership, even if it means letting them make mistakes, is the best long-term investment you can make. Building AleaPlay from scratch was the ultimate proof of that: without a great team, I never would have made it across the finish line."

Gaming Eminence: If a technically literate outsider examined Alea’s platform without context, where would they most clearly see your influence rather than the industry’s defaults? Are there architectural choices you consistently favour or resist because of how you think systems behave under stress, scale, or scrutiny?

EF: "They’d see a technical philosophy built on three non-negotiables: robustness, security, and scalability, always balanced against the bottom line, of course. But if you look closer at our software lifecycle, that’s where you really see my stamp.

For one, I’ve always resisted the idea of "legacy code." In this industry, it’s common to build a service and leave it untouched for years simply because it still functions. At Alea, we’re constantly updating everything to the latest LTS (Long Term Support) versions. It’s not just an architectural choice; it’s a cultural shift. It keeps us in total control of our systems and, more importantly, it takes the fear out of the job. Our developers aren’t afraid to jump into older projects when something breaks, because they know the stack isn’t outdated."

Gaming Eminence: Tell me about a moment when the “obvious” technical path internally or across the industry felt wrong to you. What specifically didn’t sit right, how did you articulate that concern to others, and what did the outcome teach you about when conviction is justified versus when alignment matters more?

EF: "This happens all the time when market pressure hits. I remember a specific integration with a Game Provider that was supposedly urgent because several clients were counting on its delivery. During development, we caught some potential integration flaws. The industry "standard" would have been to launch anyway and patch the bugs later, but that didn't sit right with me. I halted everything.

I sat down with the business side and explained the real impact: launching a broken product would devastate our reputation and the trust we’ve built. While it caused some initial friction because we took longer than expected, we protected the integrity of our service. It taught me that my technical conviction is non-negotiable when it comes to stability and security. If it’s just a minor visual glitch? Sure, let’s align with the business and iterate fast. But on the core stuff? I’ll always hold the line."

Gaming Eminence: Regulation, security, and platform reliability often get framed as brakes on innovation. In reality, they reshape it. How do you personally decide where experimentation is worth the operational or compliance cost and where restraint is the more responsible technical choice, even if it slows progress?

EF: "I look at it in terms of "risk radii." There’s a place for everything. On one hand, you have our CORE projects, those are sacred. We don't mess with the reliability or regulation there. On the other hand, we have side projects and internal tools where we do the exact opposite: we move fast, we break things, and we take risks.

This second tier is our laboratory. We use internal tools to play with AI, new architectures, or fresh programming languages. If something fails there, the cost is tiny, but the amount of learning we get is worth it. We still innovate on the CORE stuff, obviously, but we do it with a much tighter safety net."

Gaming Eminence: Some of the most consequential CTO decisions are made before certainty exists. When you lack clean data, consensus, or time, what internal signals tell you it’s time to commit rather than wait and how do you protect both the platform and your credibility if that decision later needs revisiting?

EF: "Honestly? It’s a bit of a CTO instinct. After years of seeing every possible high-risk scenario, you develop an internal alarm system. To protect the platform when we’re moving through the fog, my strategy is to assume we are flying blind and double down on observability.

For example, on a new or uncertain project, I’ll crank the logging levels way up, infinitely higher than a stable system. I’d much rather over-brake and deal with the temporary operational cost than not have a safety net. If something goes wrong, I want to see it the exact second it happens."

Gaming Eminence: CTO roles can quietly narrow curiosity over time. What do you deliberately do to prevent that whether through routines, reading, conversations, or stepping outside your comfort zone and how does that curiosity feed back into your leadership rather than just your technical skillset?

EF: "I’ve always been a hands-on CTO. I love development, Frontend, Backend, all of it, and I refuse to lose that connection to the actual code. In my view, if you want your team to respect your executive decisions, you have to know exactly what you’re talking about. You can't just manage from a spreadsheet.

To keep from getting rusty, I’m always working on PoCs (Proofs of Concept) or side projects. I look for the areas the company needs to explore and I dive in. It forces me to get my hands dirty with the latest tech, making sure my leadership is backed by reality, not just theory."