"CTO in Focus" Maciej Smolarek, BetGames
- Kevin Jones
- 7 days ago
- 7 min read
BetGames CTO Maciej Smolarek applies a commercially-grounded engineering lens to roadmap decisions, treating bespoke requests as market signal, not noise. His bias is toward evidence over fashion, compliance as a boundary for velocity, and personalisation as the next serious P&L lever in interactive gaming.
In this CTO in Focus, Gaming Eminence speaks with Maciej about value filtration, integration discipline, and the organisational habits that keep teams shipping in regulated environments.
Gaming Eminence: When an operator pushes for a bespoke feature, how do you decide what earns a hard no versus what shapes the product roadmap and what personal principle guides that line?
Maciej Smolarek: "I’ve learned that the real decision isn’t about whether we can build it, but whether it delivers durable value for both sides. Bespoke work can be incredibly powerful – it deepens relationships, proves we’re listening, and often sparks ideas that later become part of the core product. So, the first filter for me is always understanding the business case with absolute clarity. Once that’s solid, the line becomes surprisingly easy to draw.
It’s never only about the immediate development cost or the opportunity cost of what the team could be doing instead. I look at the full lifecycle: how much ongoing maintenance it will generate, what the long-term technical implications are, and whether the feature is a short-lived one-off or something that could become a foundation for future collaboration or even a product in its own right. Over the years, I’ve seen well-chosen bespoke features travel far – they attract other operators, they evolve, and sometimes they define entirely new value streams.
I work closely with my technical leads to make sure they understand exactly where the value lies for the client. That clarity lets us scope a true MVP without compromising outcomes, and it guides us to the right technical approach – something lean enough to deliver fast, but solid enough to extend if the market pulls us further in that direction."
Gaming Eminence: If my tech team were integrating BetGames tomorrow, what within your architecture API surface, versioning discipline, or rollback logic would tell us this stack bears your fingerprints?
MS: "I started my career as an engineer, implementing integrations myself. That experience still shapes my approach today. I know firsthand what it takes for an integration to feel “effortless”, and my goal is to make our stack reach the standard where documentation and API behaviour leave no ambiguity – the kind of clarity you see in products like Stripe, where everything you need is documented, discoverable, testable, and predictable.
But the purely technical layer is only part of the identity. The longer I lead teams, the more I’ve realised that the real signature comes from the people behind the system. Quality should reduce the need for support, but it shouldn’t remove the sense of human care. One of my favourite pieces of feedback came from a project manager at a partner studio who said she enjoyed collaborating with one of my teams because “they know everything, they have huge experience, they need almost no supervision, and they simply deliver.” That’s exactly the feeling I want our integration partners to have.
Clear interfaces, disciplined versioning, stable rollback paths – all of that matters. But the real fingerprint is that the system reflects a team that’s thoughtful, competent, and present even when it doesn’t have to be."
Gaming Eminence: Tell me about a moment you rejected a fashionable choice whether a tool, data model, or release cadence in favour of something plainer. What evidence convinced you it was the right call?
MS: "I’m naturally sceptical of anything presented as “revolutionary”. Anyone who has been in senior engineering roles long enough has seen endless waves of supposedly best-in-class tools and “game-changing” methodologies. It’s rarely about resisting new ideas – sticking to what you know is the fastest way to fall behind in this industry. The real discipline is to demand evidence.
My default approach is simple: ask for data, run a small R&D spike, understand before committing, but also fail fast! I always look for real case studies – not marketing material, but concrete examples showing that the promised results are actually achievable. Experience and a healthy dose of common sense go a long way here, as long as you remember that leadership isn’t about being the person who’s always right.
One thing I rely on heavily is the collective intelligence of the team. When you work with strong engineers, the best ideas can come from anywhere. In fact, the most innovative solution I’ve ever shipped started as a suggestion from the most junior developer in the room. That moment reinforced my bias towards evidence over fashion and collaboration over hierarchy.
The example that now comes to mind is a process that required seven different status changes, bouncing an issue back and forth between two teams. It was built with good intentions and under the banner of “perfect” ISO 27001 compliance, but the outcome was absurd: something that should have taken minutes dragged on for two days, and the same people were forced into constant context switching just to keep the process alive. It slowed the work, exhausted the teams, and added zero real value.
The solution turned out to be almost embarrassingly simple: let the two people talk directly to each other and define a single point of responsibility for reporting. Same compliance outcome, a fraction of the overhead.
Moments like that remind me how valuable it is to have hands-on experience outside corporate structures. A bit of small-business pragmatism helps you immediately recognise when a process exists only because someone once believed it should – not because it actually achieves anything. It reinforced my belief that “plain” solutions often win not because they’re conservative, but because they allow teams to move fast without compromising what truly matters."
Gaming Eminence: In a regulated live environment, how do you personally set the boundary between invention and governance? What’s one guardrail you’ve written that protects licence risk without slowing progress?
MS: "Losing compliance is a very real risk – I’ve seen firsthand how long and painful the process of obtaining licenses can be, and how quickly one mistake can jeopardise all that work. For me, the boundary between invention and governance starts with clarity of responsibility, not with restricting engineers. People can work fast and creatively as long as they know exactly who owns which part of the process.
From an engineer’s perspective, requirements are requirements – it doesn’t really matter whether they come from a product owner or a regulatory checklist. What matters is that the compliance team delivers clear, unambiguous rules, and the product owner ensures they’re implemented correctly. When those two functions are aligned, compliance becomes part of the normal workflow, not a blocker.
Some areas simply have to be done in a specific way. There’s no negotiating around regulatory constraints, just like there was no negotiating around platform rules back when I worked in free-to-play. There, two major ecosystems defined the entire playing field. In iGaming, the landscape is far more complex – more jurisdictions, more edge cases, more subtle interpretations. That’s exactly why guardrails matter."
Gaming Eminence: Looking ahead, which shift in real-time interactive gaming could genuinely move an operator’s P&L over the next 24 months and what proof would you need before betting your roadmap on it?
MS: "I’ll start with a confession: I’m not going to talk about AI as the magical answer to everything. Everyone’s doing that, us included. But why choose one direction only?
For me, the biggest P&L-moving shift over the next 24 months is real-time personalisation – and I say that having seen its impact firsthand in free-to-play. In F2P, personalisation isn’t just a feature; it’s practically a full-contact sport. Teams invest more engineering effort into predicting the optimal player configuration – how the game looks, how it behaves moment to moment, what offers surface, what bonuses land at what time – than they do into the core gameplay or infrastructure itself. I’ve seen game events released with 10k+ player-segment-specific configurations. And the results justify it: when you truly tailor the experience, session length, conversion, and retention move dramatically.
In iGaming, of course, we're working within a very different regulatory frame. Certification, fairness requirements, RTP constraints – all of that limits how far you can go in shaping mechanics dynamically. But coming from F2P, I’m convinced there’s still a massive, largely untapped opportunity in real-time game personalisation: UI/UX states, pacing, recommendations, lobby curation, bonuses the player sees, and how content is sequenced. Operators who manage to crack that in a compliant, transparent way will see meaningful uplift.
Before I’d bet our roadmap on it, I’d want proof at two levels:
1. Early, low-risk controlled experiments showing that even lightweight personalisation improves engagement efficiently – not just vanity metrics like clicks, but downstream retention and GGR.
2. Regulatory clarity that the personalisation logic is interpretable, auditable, and cleanly separated from certified RNG and RTP components. If we can show regulators that the boundary is solid, we can scale confidently.
If those two conditions hold, the case becomes compelling. I’ve watched personalisation outperform almost everything else in F2P, and there’s no reason the same core principles – applied responsibly – couldn’t become one of the biggest levers in iGaming as well."
Gaming Eminence: What conversation or habit has most sharpened your judgment as a CTO, something you now treat as non-negotiable when the calendar gets loud?
MS: "For me, it’s less about the calendar, more about realistic expectations.
There’s one question that has given me more valuable answers than practically anything else:
“If you could change one thing – in your project, in the management, in the scope, in this company, etc. – and tomorrow it would be different, what would it be?”
It’s a simple reality check, but it shows you exactly what’s on someone’s mind. I ask it across the board – engineers, managers, QA, DevOps, product, design. The answers build a kind of heat map of the organisation: what’s burning, what’s merely annoying, and what’s actually working better than we think.
People are the best thermometers. They’re professionals, deeply embedded in the day-to-day, and most of them already know how to solve 99% of the problems they face. My job as CTO is rarely to be the smartest person in the room; it’s to enable those people to fix what they already understand – and make sure nothing gets in their way."
