Two Weeks to Two Quarters: The Real Cost of Changing a Provider
- Kevin Jones
- 5 days ago
- 8 min read
Blurify's CEO and tech lead on why platform constraints have become a commercial problem rather than a technical one, and what their new framework does and does not solve.
Openora, released in July, is a modular, self-hosted framework for modernising parts of a platform rather than replacing it wholesale. It is licensed under AGPL-3.0, with a commercial licence most licensed operators will need.
The vantage point is worth noting. Blurify sells implementation work rather than a platform, so its account of why operator stacks resist change comes from the delivery end, not from a vendor defending its own incumbency.
Openora is alpha. CMS, casino and sportsbook adapters and a fully working wallet are still to build, no provider integration is production-certified, and the licensed operator remains the accountable entity throughout.
CEO and co-founder Adam Mateja and tech lead Volodymyr Zakhovaiko cover where platform boundaries fail, how to choose a first migration target a board will fund, why reconciling player and transaction history is harder than writing new modules, what "AI native" means once the marketing is removed, and why money, eligibility and regulatory configuration stay with human reviewers.
The interview begins below.
Gaming Eminence: Operators often say legacy technology is holding them back from launching products, entering markets or responding quickly to regulatory change. Where do those problems usually begin, and when is incremental modernisation not the right answer?
Adam Mateja: "From a business perspective, the problem usually becomes visible when the platform can no longer keep pace with the operator’s strategy. A company may want to enter a new market, introduce a different payment method or respond to a regulatory change, but what appears to be a seemingly small commercial initiative turns into a major technology project. That creates a widening gap between business ambition and delivery capability.
The cost goes beyond development hours. Operators lose opportunities because they cannot launch quickly enough, negotiate effectively with providers or test new propositions without committing significant resources. Over time, technology stops being an enabler of growth and becomes a constraint on it.
Incremental modernisation is attractive because it reduces disruption and allows the operator to prioritise investments according to business value. However, it is not a universal answer. If the organisation cannot define clear ownership of systems, data or decision-making, adding another architectural layer may only increase complexity.
In those cases, the first step is not necessarily migration. It’s establishing a clear operating model: which capabilities create competitive advantage, which should remain external, and which parts of the platform need to become independently replaceable."
Volodymyr Zakhovaiko: "The problem is rarely the age of the stack itself. It is usually that the system boundaries were drawn by whichever integration had to be delivered fastest, rather than by what the business needed to change independently. A wallet begins to know about the payment provider. The KYC flow becomes dependent on the player database. The lobby starts relying directly on the aggregator’s response format. Nobody intentionally designs a platform this way. It evolves one provider, market and integration at a time.
Commercially, it shows up as unexplained delay to time-to-market. Adding a payment method for a new market may look like a two-week integration, but in reality it becomes a two-quarter project because it affects the player application, risk rules, reporting and several adjacent systems. The real cost is not the integration itself, but the regression surface around it. A useful technical test is whether an operator can replace a provider without redeploying anything the player interacts with.
In Openora, providers such as PSPs, KYC services and game aggregators sit behind adapter interfaces. They’re connected through explicit ports and typed dependency-injection tokens, so changing a provider should mean implementing a new adapter and updating configuration rather than rewriting business logic.
Incremental modernisation stops working when the team cannot explain where one module ends without opening several other repositories. At that point, the boundaries need to be redesigned first. The new components can then run alongside the existing platform and gradually take over responsibility. It is closer to a strangler pattern than a full rewrite, but the boundaries are decided deliberately rather than discovered during the migration."
Gaming Eminence: Openora is designed to let operators modernise parts of their platform without replacing everything at once. How would an operator decide where to start, and which dependencies tend to make that process more complicated than it first appears?
Adam: "The starting point should be selected according to business impact, not which part of the codebase appears most outdated.
We would normally look at three factors:
how often the capability needs to change;
how strongly it affects revenue, cost or market entry;
how exposed the operator is to a single provider.
Payments and KYC are strong examples because they influence market access, conversion, operating costs and regulatory responsiveness. If replacing a provider takes several months, the operator’s negotiating position is weakened. Making that dependency replaceable can create an immediate commercial benefit.
The first modernisation initiative should also be narrow enough to control but important enough to demonstrate value. It needs a measurable outcome: reducing the time required to integrate a provider, shortening release cycles, lowering operational cost or allowing the business to enter a market faster.
That is easier to support at board level than a broad technical objective such as “improving the architecture”. Operators should also be realistic about the organisational dependencies. A migration may expose unclear ownership between product, engineering, compliance, finance and external providers. Those organisational dependencies often affect delivery more than the technology itself."
Volodymyr: "Technically, I would start where the frequency of change and vendor risk are highest, not where the code looks worst. The bigger challenge is usually data rather than code. Building the new module is often the easy part. Reconciling years of player and transaction history so the new wallet doesn’t disgaree with the existing ledger is much harder. During a phased migration, both systems may temporarily remain authoritative for different areas. The operator needs an independent way to verify that their outputs agree.
Openora supports that phase in two ways. State-changing actions are recorded in an append-only, SHA-256 hash-chained audit log, providing an independent reconciliation record instead of forcing teams to compare two live databases. Each module also owns its own migration history, so migrating one capability doesn’t automatically pull the rest of the platform schema into the same project.
Another commonly underestimated dependency is identity. Sessions, roles and permissions tend to spread across the entire platform. Whichever module is selected first will usually bring authentication and authorisation concerns with it, so those need to be included in the scope from the beginning."
Gaming Eminence: There is a lot of loose language around what makes technology “AI native”. In practical terms, how does Openora change the way developers build, test and maintain a platform, and where does human oversight still need to remain firmly in place?
Volodymyr: "Most "AI native" claims mean a model was added to the product. Ours means the platform is built to be legible to an agent as a first-class consumer of the codebase, and the payoff is lower development costs, not another product feature.
In practice, every shape in the system is a Zod schema, so contracts are introspectable rather than described in prose. Every module ships an AGENTS.md covering the invariants and extension seams that code cannot express. There’s also a generated machine-readable catalogue of routes, schemas, adapters, and events, and an MCP server that exposes the schema registry, route catalogue, and scaffolders as tools. An agent asks the platform what exists instead of grepping and guessing, and it does not re-derive that context every session.
The wiring is deliberately explicit for the same reason. No decorators, no auto-discovery, a functional DI container with typed tokens. Magic is what makes a codebase unreadable to a model, and to a new engineer in month one. Those turn out to be the same problem. The business effect is that a mid-level engineer with an agent can ship a module correctly, because the guardrails are mechanical: boundary linting, contract validation, and module shape checks all run in CI, so incorrect changes fail the build before reaching review.
Human oversight stays firmly on anything that moves money, decides eligibility, or touches regulatory configuration. Wagering logic, KYC outcomes, compliance rules, and payout paths go through reviewed code and leave an audit entry. AI accelerates the scaffolding around those decisions. It does not make them yet."
Gaming Eminence: Openora includes interfaces for areas such as payments, KYC, and game aggregation, although some production integrations are still on the roadmap. What would an operator need to build or source itself today, and who ultimately carries the risk when those systems are connected during a phased migration?
Adam: "Our objective is to give operators control over how their platform evolves, rather than deciding their provider strategy for them. Payments, KYC and game aggregation are not neutral infrastructure choices. They affect margins, regulatory coverage, player experience and the operator’s ability to negotiate commercially. Bundling a default provider into the framework could create a dependency that the operator would later need to remove.
Today, an operator adopting Openora would still need to select the relevant providers and either build or commission the required production adapters. Those integrations would also need to go through the appropriate certification and compliance processes for the jurisdictions in which the operator is active. That work should be reflected honestly in the implementation plan. Openora provides the architectural foundation and makes the integration replaceable, but it does not remove the need for provider-specific implementation and certification.
Responsibility must also remain clear. The licensed operator retains regulatory accountability, provider relationships and final compliance approval. Blurify is responsible for the quality and integrity of the framework and for delivering agreed engineering work correctly. We see transparency around that division as essential to building trust with enterprise operators."
Volodymyr: "Openora provides the integration seams rather than production-certified connections. Operators still choose their providers, build or source the relevant adapters and complete the required certification process.
The risk boundary is deliberate. The operator owns:
provider selection;
compliance approval;
jurisdictional coverage;
infrastructure and configuration;
the commercial relationship with each provider.
We are responsible for the framework being technically correct: maintaining sound boundaries, reliable contracts and the integrity of the append-only audit trail. During phased migration, the highest-risk points are the joins where an old and a new system can both affect the same balance or state. Those joins require an operator-owned reconciliation process. Openora provides the audit data against which that reconciliation can be performed, but it does not become the regulated entity."
Gaming Eminence: Openora is still described as an alpha framework and is not yet recommended for production without an operator’s own review. What needs to happen before it is ready for a regulated live environment, how would responsibility for security and compliance be shared, and when would an operator need a commercial license rather than using the AGPL version?
Volodymyr: "Three things need to happen before we would call it production-ready for a regulated environment.
1) The roadmap gaps close: CMS, fully working wallet, casino, and sportsbook adapters are not built yet.
2) Contract stability, which only comes from real deployments applying pressure to the APIs before we freeze them at 1.0.
3) Certified reference adapters for at least one provider per seam, so the integration path is proven rather than theoretical.
We call it alpha because that is what it is. An operator planning a licensed launch should treat it as a framework they are adopting and reviewing, not a finished product they are buying.
Responsibility is clearly divided. We own correctness of the code, the integrity of the boundaries, and the audit chain, plus private vulnerability reporting and disclosure. The operator owns their own security review, their adapter choices, their infrastructure and key management, and compliance in every jurisdiction they serve. Anyone taking this into a licensed environment should budget for an independent security assessment. That’s standard practice for any real-money platform, regardless of the framework.
On licensing, the test is straightforward. AGPL-3.0 works if you self-host and are willing to publish your complete corresponding source, including under Section 13 when running it as a hosted service. That’s exactly what a player-facing platform does. You need a commercial license when you want to run closed-source SaaS on it, embed it in a product distributed under other terms, or need warranty, indemnity, or an SLA that the AGPL's "as is" terms cannot give you. In practice, most licensed operators land in the commercial column, and that is by design rather than a trap."
