Orbital Long
In-house backend platform for operating and automating multi-brand casino businesses at scale.
Orbital is an in-house backend platform built to run and automate complex, multi-brand casino operations. It centralises users, wallets, payments, transactions, game integrations, CRM, localisation, licensing, and promotional logic into a single operational core.
The platform was created to replace an ecosystem of over 150 disconnected tools and rigid third-party partners, consolidating that complexity into a configurable, no-code system designed to scale across markets and regulatory environments with minimal engineering overhead.
Orbital consolidates that complexity into a configurable, no-code platform that reduces operational risk, lowers cost, and enables rapid product change with minimal engineering overhead.
Client
Armstrong Operations
Skills
Product design
Design systems
Design tokens (JSON / Git)
Information architecture
UX Research
Prototyping
Wireframing
CMS and configuration design
Data modelling (content, rules, localisation)
Figma
My role
Product Design Lead
Timeline
Q4 2023 - Q1 2026
Team
Leon Storm, Vio Cojacaru, Martin Eneqvist, Jonas Erickson, Haris Veveris, Alex Collins, Gaz Stevens, Kalman Speier, Krisztian Petrucsik, Roland Heli, Veigar Ragnheiðarson, Nils Wieslander, Oliver Fagerdahl, Markus Krefors, Jon Olsen, Linus Eriksson, Kim Hansson
A schema-driven CMS that defines page structures, fields, and localisation rules before content is created.
A fragmented operational reality
Orbital emerged from an operational environment defined by fragmentation, risk, and diminishing returns.
The business was running on an ecosystem of more than 150 tools, services, and libraries, stitched together through fragile integrations and expensive third-party platforms. Core operational functions such as payments, CRM, game management, localisation, licensing, and reporting were split across vendors with overlapping responsibility and little shared context.
This created three systemic problems:
Operational scale was tied directly to headcount and manual effort
Risk exposure was dictated by external platform limitations
Product change required engineering intervention for routine configuration
As the business expanded into new brands and markets, these issues compounded.
Payments became the primary blocker in grey and regulated markets. Market entry was constrained by third-party licensing and game availability. Regulatory confidence varied by partner rather than by internal standards.
Orbital was conceived as a replacement for this model, not an addition to it.
A single operational view to review user status, activity, payments, gameplay, and compliance actions.
Understanding failure at scale
Research focused less on user discovery and more on failure analysis across real operational workflows.
Technical Constraints
Mapping constraints, not opinions
Research focused on understanding where the existing operational model failed under real conditions. Rather than abstract user needs, the work centred on identifying structural constraints that limited scale, safety, and speed.
Tool sprawl
Operating the business required more than 150 tools, platforms, and libraries. Responsibility for core workflows was distributed across vendors with overlapping domains, inconsistent data models, and incompatible assumptions. No single system held authoritative context.
Third-party rigidity
Most external platforms offered surface-level configuration but enforced rigid behaviour beneath. Seemingly small changes to rules, payments, or promotions often required workarounds or vendor involvement, introducing cost, delay, and risk.
Manual operational load
Where automation failed, humans compensated. Teams relied on manual checks, spreadsheets, and ad-hoc processes to reconcile data, manage exceptions, and resolve payment or CRM issues. Scale was achieved through effort, not systems.
Payments as a structural bottleneck
Payments were the most fragile part of the stack. Provider limitations, market restrictions, and inconsistent failure handling made payments the primary blocker for expansion, especially in grey and regulated markets.
Market and regulatory fragmentation
Each market introduced its own mix of licensing, compliance, formatting, currency, and localisation requirements. These differences were handled through duplication rather than configuration, increasing divergence and operational risk.
Hidden coupling between systems
Changes in one platform often produced unexpected effects elsewhere. Game availability, promotions, payments, and CRM logic were tightly coupled across tools without explicit contracts, making behaviour hard to predict and harder to trust.
False flexibility
While many tools appeared flexible in isolation, they could not be safely extended together. Tool sprawl existed because no single platform could absorb new requirements without breaking existing ones.
These constraints made it clear that the problem was not usability or tooling choice, but the absence of a single system designed to own and enforce operational rules.
Designing a system that absorbs complexity
Orbital was designed as a deliberate replacement for fragmented tooling, not a unifying layer on top. The solution was to build a single operational platform that treats markets, brands, rules, and risk as first-class system inputs.
Solutions
One owned operational core
All critical casino functionality lives inside a single, in-house platform. Users, accounts, wallets, payments, games, CRM, content, localisation, licensing, and reporting operate within the same system boundaries, sharing a common data model and source of truth.
This removes hidden coupling between tools and makes system behaviour explicit rather than emergent.
Configuration instead of duplication
Brands and markets are not duplicated as separate systems. Differences are expressed through configuration layers that define rules, availability, content, and compliance requirements.
Markets differ by constraints, not code forks.
Brands differ by parameters, not infrastructure.
This allows new brands or regions to be launched without introducing long-term divergence.
One owned operational core
All critical casino functionality lives inside a single, in-house platform. Users, accounts, wallets, payments, games, CRM, content, localisation, licensing, and reporting operate within the same system boundaries, sharing a common data model and source of truth.
This removes hidden coupling between tools and makes system behaviour explicit rather than emergent.
One owned operational core
All critical casino functionality lives inside a single, in-house platform. Users, accounts, wallets, payments, games, CRM, content, localisation, licensing, and reporting operate within the same system boundaries, sharing a common data model and source of truth.
This removes hidden coupling between tools and makes system behaviour explicit rather than emergent.
One owned operational core
All critical casino functionality lives inside a single, in-house platform. Users, accounts, wallets, payments, games, CRM, content, localisation, licensing, and reporting operate within the same system boundaries, sharing a common data model and source of truth.
This removes hidden coupling between tools and makes system behaviour explicit rather than emergent.
One owned operational core
All critical casino functionality lives inside a single, in-house platform. Users, accounts, wallets, payments, games, CRM, content, localisation, licensing, and reporting operate within the same system boundaries, sharing a common data model and source of truth.
This removes hidden coupling between tools and makes system behaviour explicit rather than emergent.
Orbital replaces reactive tooling with deliberate operational infrastructure.
It is designed to scale through structure, not effort.
Algorithmic rules engine: Composable, trigger-based logic that categorises users and controls behaviour across markets, providers, and transactions.
