Stay updated

INTERVIEW  NOVEMBER 2026

Interview with Adam Mateja: Operators should modernise what holds them back, not rebuild everything

By Published

Blurify's co-founder on AI agents as contributors and giving operators control over their platforms.

Interview

Our editor had a conversation with Adam Mateja, CEO and co-founder of Blurify, about a challenge facing many iGaming operators: how to develop their technology without taking on the cost and risk of replacing established platforms. Having built a software business from the final months of university onwards, Mateja has seen how operators can become constrained by systems they are reluctant to change. He believes modular architecture and AI-assisted development could offer a more incremental route to modernisation — provided that speed does not come at the expense of accountability.

Adam Mateja, Co-founder and CEO of Blurify, smiling with arms crossed

Adam Mateja, Co-founder and CEO, Blurify. Image courtesy of Blurify

Adam Mateja — Co-founder and CEO, Blurify

Current Title: Co-founder and CEO

Company: Blurify

Product discussed: Openora, a modular, AI-native iGaming framework, available under the AGPLv3 open-source licence or a commercial licence.1

From a university start-up to iGaming technology

Mateja began building Blurify while he was still in the final months of his computer science degree. He and his business partner initially worked on the company alongside other jobs, earning money to pay the bills before deciding to commit to the business full-time.

“I started the company right after my studies, actually even during the last months of the study,” he says. “Basically, my whole career life I am on my own. There are pros and cons of doing that.”
His technical education was useful in the early years, when he was still involved in development himself. Today, he says, he is “hiring smarter people than me” for the development work, but believes his background helps him understand internal discussions as well as conversations with clients and partners. He describes his co-founder as the more technical of the two, making their skills complementary.
The company began in 2015, when the founders were in their early twenties. At first, they accepted a broad range of projects: websites, e-commerce work, internal tools and other software products. The priority was to build the business and take on the work available to them.
Then, after a few years, came iGaming. “By accident, as many things in our life, we started to work on our first iGaming project for an operator,” Mateja says. Before making the leap, Blurify had worked in iGaming for both operators and game studios. At the time, the founders were weighing two directions, health technology and iGaming. iGaming became their market, with the work on operators’ platforms proving the most interesting.
As the projects grew larger, Mateja and his business partner began to see an opportunity in concentrating on a particular industry rather than continuing to work across a broad range of software assignments.
Eventually, they decided to remove the other services from the company’s website and focus on iGaming. It was a hard decision, he says, because it meant saying no to other projects and the revenue that came with them. “What if” only e-commerce clients came looking, the founders wondered. “But it was the decision, and right now I think it was a good one.”
That experience helps explain why he is interested in the problem of platform modernisation today. The recurring issue for Blurify’s operator clients was the limitations of their platforms: their ambitions were not always matched by the technology they were using.
Mateja sees two sides to the industry. On one side, companies invest heavily in new technology and experiment with different approaches. On the other, some legacy platforms continue to generate strong business, particularly where operators have effective affiliate relationships and established traffic.
Yet the limitations can become apparent when the operator wants to do something new. Mateja says that adding a single provider to an existing platform can sometimes turn into a major technology project because teams are afraid to touch the code.
The result is a difficult balance. A turnkey platform can offer a practical route into the market, but the operator may have to accept the provider’s roadmap and limitations. Replacing the platform can offer more control, but migration projects are expensive, lengthy and risky. “Those projects can take one year and a half, sometimes even more than two years, or even longer if we were talking about very, very large system,” Mateja says. Operators complain about their platforms, he says, but they are also afraid that another platform project will take a year or two, may not succeed and will cost millions.
This is the problem Blurify is trying to address through Openora: not the assumption that every legacy platform should be replaced, but the possibility that operators could change the parts that constrain them without having to rebuild everything at once.
Four Blurify team members working on laptops around a meeting table in a bright office

Blurify’s team at work in the company’s office. Image courtesy of Blurify

Making time to rethink how the team works

“Every day we are learning,” Mateja says of AI at Blurify. A large chunk of the software the company builds today is already produced by AI, he says, but new tools appear every day. So Blurify gives its people time to rethink their current approaches and what they can do next.

“Someone maybe can say that this should be already established,” he says. But the field is developing so fast that he thinks it is worth looking, at least every few weeks or each quarter, at whether there are new ways or new approaches to using AI.
The rethinking reaches beyond the software department, into project management, marketing, sales and finance. A large part of the company’s quarterly goals is about how much AI it wants to use in the coming months, which processes to automate and what savings to achieve, whether in resources or in the use of external companies.
That reflection is beginning to affect how the company organises software development. Mateja describes a recent discussion among engineering leaders about revisiting the software development lifecycle and whether some roles could be combined or expanded. One possibility is that business analysts, using appropriate tools, could take on part of a project’s quality assurance work. Blurify is also putting greater emphasis on hiring full-stack developers.
The underlying idea is that people may no longer need to remain confined to one part of the development process. As AI takes on more implementation work, teams will have to adapt their responsibilities and decide where human expertise is most valuable.

Building software with AI agents as contributors

Openora takes this thinking further by building AI into the framework’s design from the beginning. Mateja makes a distinction between using AI as a coding assistant and treating an AI agent as a contributor to the project.
“With Openora, this was really thought through from the very beginning, that this project will be AI-native across all its parts,” he explains. “The AI is really kind of a contributor to the project, not just a tool that a developer is using.”
The framework is structured to help agents understand the software they are working with. Mateja points to contracts, routes and schemas, alongside agent-specific documentation, MCP tooling and architectural guardrails. The aim is to give agents a clearer view of the codebase and its conventions so that they can contribute within a defined structure.
Mateja argues that because the agent has full knowledge of the project, the risk of hallucination is “limited to zero”. Openora’s documentation sets out how agents are guided and how their work is tested and reviewed, but it does not promise error-free code.2
The intended change is in how developers spend their time. If agents can help produce routine features and supporting functionality, engineers can concentrate more on architecture, product decisions and the areas where human review is particularly important.
For operators, the potential benefit is not only that software could be built more quickly. Mateja believes cheaper and more accessible development could make it easier to experiment with new features, adapt products to particular markets and distinguish an offering from competitors. Instead of spending time and money repeatedly implementing capabilities that every operator needs, teams could focus more of their attention on the features that make a genuine difference to their product.
There are clear limits, particularly in iGaming. Mateja says Blurify cannot simply allow AI to do everything in an industry involving money and compliance. Player funds, regulatory requirements and adjustments to different jurisdictions are areas where human involvement remains necessary.
That boundary also applies to the way operators use AI-generated code. An agent may contribute to implementation and testing, but it does not assume responsibility for what the software does.

Industry perspective

“You should build what you need, you should modernise what is holding you back, and you should migrate only when it really makes sense for the business.”

— Adam Mateja, Co-founder and CEO, Blurify

Around 30 members of the Blurify team in matching Blurify hoodies, posing together on a grassy hillside with trees and hills behind them

The Blurify team. Image courtesy of Blurify

Open source, ownership and operator accountability

Openora is intended to provide an alternative to the familiar choice between buying a ready-made platform and undertaking a major migration. The framework is modular and dual-licensed. The core is open source under the AGPLv3 licence, and operators that want to keep changes to the framework core private can take a commercial licence instead. Openora’s documentation distinguishes those core changes from operators’ own plugins and integrations, which can remain proprietary.1 It is designed to let operators build the capabilities they need, modernise constrained parts of their technology and retain more control over their technical direction.
Mateja argues that operators should not have to spend time and money rebuilding standard functions simply to gain the freedom to develop a distinctive product. Wallets and reporting, for example, may be necessary, but they do not necessarily give an operator a competitive advantage. He would rather see development focused on areas such as retention, social features and adapting the product to the markets in which the business wants to operate.
According to Mateja, projects built on Openora can be completed in under a year, and in some less demanding jurisdictions within six to eight months.
Openora launched on 9 July 2026. “It was launched on my birthday,” Mateja says. The first operator on the framework is due to go live in early December, he says, and a second project is being built. A few more operators are in talks about joining. “The interest is there,” he says.
Ahead of SiGMA World in Rome, held on 2–5 November 2026,3 Mateja described the event as Openora’s first exhibition. He said he was looking forward to talking to potential customers, gathering feedback and presenting the product to a broader audience.
Open source is central to the model because it allows an operator and its technical team to inspect and validate the technology before committing to a project. Mateja says the intention was not to create another closed platform in an already crowded market. An open foundation can also enable a wider group of contributors to develop plugins and integrations.
He describes building an ecosystem that could include game studios, payment providers and other third-party suppliers, with a marketplace through which operators can choose from available integrations. The commercial licence exists, he says, because operators want to keep certain intellectual property private.
The model therefore brings together two priorities Mateja identifies as fundamental to the project: freedom and ownership. Operators can examine the open-source core, decide how they want to extend it and, through the commercial licence, keep changes to the framework core proprietary.
According to Openora’s published information, operators can self-host Openora and keep control of their business logic, player data, infrastructure and security. Openora charges no recurring GGR share or transaction fees, though operators still pay for hosting, third-party services and, where needed, a commercial licence.1
But openness and AI-assisted development do not remove the need for accountability. Mateja is explicit that the operator remains responsible for compliance and decisions affecting players, regardless of whether AI helped write the code. Wagering logic and compliance-related functionality require appropriate human review.
Those obligations are concrete. In Britain, compliance with the Gambling Commission’s remote gambling and software technical standards is a licence condition. Its security requirements cover systems that hold customer data, generate game outcomes or store the state of a customer’s gamble, and include controls on change management, logging and a secure development life cycle.4
He also says Openora records state-changing actions so that teams can trace what happened within the framework.

The framework is still young. According to its own documentation, it has not been through an external security audit and does not come with RNG certification, which remains the responsibility of the operator and its game providers.5

Everyone is already using AI, Mateja says. “Using AI will not be an advantage of itself if everyone is doing that.” The difference, in his view, lies in gathering the data, drawing wise conclusions and translating them into features that change the numbers.
That brings the discussion back to the limitations of established platforms. Some operators may have little reason to replace technology that continues to support a successful business. Others may find that the cost and risk of change are preventing them from pursuing new opportunities. A modular approach could allow them to make those decisions component by component, rather than treating modernisation as an all-or-nothing project.

For Mateja, the point is ultimately about giving operators greater freedom to decide how their technology develops. They may choose to build something new, modernise a constrained part of the stack or leave a working system alone. As AI changes the economics of software development, will operators gain more control over those choices — or will platform limitations continue to determine what they can build?

Article written by Elisabet Johansson

Sources and research notes

  1. Openora, Casino platform pricing without a GGR share, accessed 6 November 2026. Describes AGPLv3 and commercial licensing, including the distinction between changes to the framework core and proprietary extensions, and separates platform fees from licensing and services.
  2. Openora, Agentic Workflow, accessed 6 November 2026. Describes agent guidance, testing, code review and release checks; these processes do not establish that AI-generated code is error-free.
  3. SiGMA World, The essential guide to SiGMA World 2026, 9 October 2026. Confirms the Rome event and its 2–5 November dates. Openora’s exhibition plans are Mateja’s account.
  4. Gambling Commission, Remote gambling and software technical standards: Introduction (updated 20 March 2026) and Security requirements (updated 4 November 2024), accessed 6 November 2026. Covers the licence condition, critical systems and controls on logging (8.15), secure development (8.25) and change management (8.32).
  5. Openora, Compliance & Audit Trail, “What this is not”, accessed 6 November 2026. The supplier states that the framework has not undergone an external security audit and includes no RNG certification. This describes the framework, not the approval status of any individual operator.

This article was shared with Adam Mateja / Blurify prior to publication for factual review. The 9 July launch date and the December operator-launch timetable are attributed to Mateja’s interview account; the latter remained a plan at publication. External sources were checked on 6 November 2026.