Build, License or Acquire an RGS?

A studio that wants more control over how its games get distributed eventually runs into a fairly large question: what to do about the RGS.

Build one. License one. Or start from an existing RGS codebase and take it forward internally.

There's no single correct answer here — just one that tends to fit the company you actually are today.

Before choosing between the three, there's a simpler question worth asking first: do you need your own RGS at all?

Maybe not. If you're running a small portfolio of games, already have a route to operators, and have no particular reason to control the infrastructure underneath, owning or operating an RGS can solve a problem you don't have.

An RGS buys you control. It also buys you platform engineering, integrations, deployment, monitoring, transaction handling, reconciliation, operational tooling, and the job of keeping all of that working while the games keep evolving. If someone else already does that well, at a price and on terms you're fine with, that's a perfectly reasonable arrangement.

The decision gets more interesting once the platform itself starts to matter — operator integrations becoming central to the business, wanting control over your own deployment and roadmap, or someone else's platform starting to shape what you're allowed to build.

From there, three broad paths.

Build

Build it when the platform is part of the strategy.

There are good reasons to build an RGS from scratch. Your requirements might be unusual. You might already have a strong platform team and a clear architectural view. The RGS itself might hold capabilities you consider strategically important. Or you simply want full control over a platform you plan to run for years.

Just be careful what "building an RGS" actually means. Game launch, sessions, rounds, and wallet calls are the obvious parts — they're also the parts that show up on the first architecture diagram. Then come operator integrations, retries, duplicate transactions, failure recovery, reconciliation, configuration, reporting, observability, deployment, and support tooling — the behaviour that only accumulates after real systems have spent time disagreeing with each other.

Version one is not the end of the build. Building an RGS means committing to keep building it. For a company that wants the platform itself to be part of its engineering advantage, that's the whole point. For everyone else, it's worth sitting with before signing up.

License

License it when owning the machinery isn't the point.

Say your real advantage is elsewhere. You make excellent games, you have a strong pipeline, and you want distribution across more operators — what you don't particularly want is a platform engineering programme running alongside the game studio.

Licensing an RGS, or using one as managed infrastructure, can be an entirely rational answer. Much of the engineering underneath the games becomes somebody else's problem. Operator connectivity may already exist. Platform maintenance and operations may sit partly or fully with the provider, which can save a serious amount of time and effort.

What you give up is control. You're operating inside someone else's architecture, commercial model, and roadmap, with real limits on what you can change and how fast. If the provider becomes a constraint later, moving away won't be trivial.

For some studios that barely matters — they'd rather spend the next twelve months making games than operating a platform. It's simply a decision about where the engineering time is worth spending.

Acquire

Start from existing source code when you want the head start and the control.

There's a third option that gets discussed less: instead of building from zero or staying on somebody else's operated platform, start from an existing RGS codebase available through source-code handover, deploy it in your own environment, and take it from there.

The appeal is straightforward. A large amount of foundational work already exists, so you start with working platform capabilities instead of an empty repository, while keeping considerably more control over deployment, modification, and direction than a managed platform allows.

But taking the source code doesn't remove the operational job.

Source code is not managed infrastructure.

Once your team controls the platform, the platform is your problem — someone has to understand it, deploy it, monitor it, integrate new operators, diagnose failures, and evolve the architecture as requirements change. Over time, your version may drift substantially from what you started with.

If you don't want that responsibility, acquiring source code can be a worse decision than licensing. If you do want it, and don't see much value in spending a year or two rebuilding well-understood RGS machinery before getting to the work that actually differentiates you, this option gets a lot more interesting.

What are you actually optimising for?

The three models solve different problems.

The table is deliberately qualitative. A mature licensed platform can get you live faster than an immature acquired codebase. A strong internal team can build faster than the table implies. A badly chosen foundation saves less than it promises. Use it to structure your own analysis rather than as a final scorecard.

Our bias

We build RGS technology, so we're not exactly disinterested here.

Still, the view is fairly simple. If the RGS is strategically important enough that you want to invent its architecture, own every engineering decision, and keep investing in the platform as a product in its own right — build it. If the RGS is infrastructure you need rather than infrastructure you want to get expert at operating — license it. If control matters, your team can genuinely own the platform, but spending years recreating fairly well-understood RGS engineering doesn't sound like the best use of that time — starting from an existing codebase deserves serious consideration.

The wrong choice is usually the one made on a wrong idea of what happens next: building doesn't stop at version one, licensing doesn't remove dependency, and taking the source code doesn't remove the engineering.

Where SPHINX fits

SPHINX exists partly because we think there's useful ground between building an RGS from zero and staying permanently dependent on someone else's platform. It's a working Remote Gaming Server foundation available through source-code handover, licensing, and managed deployment models.

Which model makes sense depends on what you want to own, what you're happy to hand off, and where you want your engineers actually spending their time.

Explore SPHINX →