Should you build or rent an RGS?

Building a Remote Gaming Server (RGS) in-house typically costs several hundred thousand euros and 12 or more months of development before the first certified game earns money. Renting a hosted RGS costs EUR 500 to EUR 3,000 per month plus transaction fees and puts games in production within days. A third path sits between the two: rent first, then buy the platform source code once the economics justify full ownership.

The decision is less about which option is cheaper and more about what a studio's actual business is. If the business is making games, the platform is a means to an end and every month spent building it is a month of games not shipped. If the business is owning gaming technology, building or buying makes sense. This page lays out the comparison honestly, including the cases where renting is the wrong answer. If you first want to understand what an RGS consists of, start with What is a Remote Gaming Server (RGS)?.

The three paths

Build vs rent, dimension by dimension

The honest internal calculation

There is a reason in-house always looks cheaper in a meeting: a rented platform arrives as an invoice, while an in-house platform hides inside payroll. A EUR 1,500 invoice feels like a cost; a EUR 10,000 senior engineer feels like a team. So model it honestly, at three studio sizes, counting only what payroll and infrastructure actually absorb, and put it next to what a studio of that size actually earns:

Assumptions: senior engineer at EUR 10,000 per month fully loaded. Tiny studio: one engineer plus EUR 500 minimal hosting, against hizi.basic at 2M transactions per month (EUR 1,500 + EUR 240). Small studio: two engineers, half an FTE of DevOps, EUR 2,000 hosting, against hizi.standard at 10M transactions (EUR 3,000 + EUR 1,000). Growing studio: three engineers, a full DevOps FTE, EUR 4,000 hosting, against hizi.standard at 40M transactions (EUR 3,000 + EUR 4,000). Studio income modeled at an average stake of EUR 0.50, average RTP of 95% (EUR 25,000 GGR per 1M transactions), and a rev-share of 8% of GGR, so EUR 2,000 income per 1M transactions. Engineering covers both platform (RGS) and game-engine work: one person doing both jobs in the tiny setup, roughly half RGS and half engine at small and growing scale. Game certification excluded on both sides, since games are lab-certified whichever platform they run on.

Note what the engineer figures actually stand for: an in-house stack needs two different jobs done. Someone has to build and maintain the RGS itself, the wallet, transactions, and operator integrations, and someone has to build and maintain the game engine the studio's titles run on. In the tiny setup, one person does both, which is its own risk. At small and growing scale, the headcount splits roughly half and half between the two. Renting replaces both jobs at once, because a hosted platform like hizi ships with the engine included. And on hizi that engine is hizi.engine, a no-code game-engine builder, an industry first, included in every tier: math models, RTP variants, paytables, and features are configured in the browser rather than programmed from scratch. That shrinks two lines at once, the platform payroll and the engineering each new title needs.

The pattern is the point: the ratio barely moves with size. The tiny setup, one engineer and a minimal server, is already generous to the in-house side; it assumes no redundancy, no second pair of eyes on code that settles real money, no vacation cover. It still runs about 6 times the rented equivalent. Scale the team up to something actually defensible and the ratio stays between 6x and 7x, every month, indefinitely, because the rented platform's usage fees grow far slower than headcount. The model also leaves out everything soft: recruiting, churn, management overhead, and the months of building before any of this even runs.

The income line makes it concrete. At tiny scale, the in-house platform costs about two and a half times the studio's entire rev-share income; the studio is structurally loss-making before it has made a single game. At small scale, EUR 27,000 of platform against EUR 20,000 of income, it is still underwater. Only at the growing stage does income finally clear the in-house bill, and even then the platform eats over half of it. The rented platform, by contrast, stays below the income line at every size: around 44% of income at tiny scale, 20% at small, and 9% at growing, falling as the studio grows. In-house, the platform alone consumes more than the studio earns until well into the hundreds of thousands of euros in monthly GGR.

At the small-studio size, the difference is about EUR 23,000 a month, and it buys exactly one thing: control. Whether that control is worth more than the two additional games a year it could fund instead is the real build-vs-rent question.

When building is the right call

Honesty requires naming the cases where renting loses. Build your own RGS if platform ownership is the product: you plan to license the technology to others, your game concepts need engine capabilities no hosted platform offers and never will, or you operate at a scale where per-transaction fees exceed the fully loaded cost of a platform team. Build also if regulatory strategy demands it: some corporate structures want the certified platform inside their own legal entity from day one.

What building does not solve is speed or cost for a new studio. The first year of an in-house build produces zero revenue by definition, and the platform team remains a fixed cost whether the studio ships two games or twenty.

When renting is the right call

Rent if the business is games, not platforms. A rented RGS turns the platform from a capital project into an operating cost that scales with success: EUR 1,500 to 3,000 per month plus transaction fees that only grow when the games are actually being played. The certification burden for the platform layer, the operator integrations, and the maintenance all sit with the provider. On hizi, the included no-code engine compounds the effect: because games are configured rather than engineered, the cost per title falls along with the platform cost, and the engineering budget goes into game ideas instead of game plumbing. The full price comparison is in How much does an RGS cost in 2026? and on the pricing page.

The honest downside of renting is dependency: the provider's roadmap is not yours, and switching platforms later means re-integrating games. Two contract features determine how serious that dependency is. First, the terms: month-to-month rental under online T&Cs, as on hizi.io, means the provider has to earn the relationship every month, unlike multi-year lock-ins negotiated behind NDAs. Second, the exit path, which brings us to the third option.

The third path: rent first, buy the source later

hizi.io offers a one-time source-code licence at EUR 250,000. That changes the build-vs-rent question fundamentally, because it removes the permanence from both sides of the trade-off. A studio can launch on a rented plan in days, earn revenue immediately, and treat sovereignty as a later decision made with real numbers: once monthly fees and transaction volume reach the level where ownership pays, buy the source of the exact platform the games already run on. No migration, no rebuild, no re-certification of game logic against a new engine.

Compared to building from zero, this path costs less than a typical in-house build, compresses platform development time to zero, and swaps an unproven platform for one that is certified and running in production. Compared to renting forever, it caps the dependency: the exit is priced and contractual, not hypothetical.

The bottom line

As of August 2026, the default answer for a new or growing studio is rent, with the source-code option held open. Build only if the platform itself is your product or your scale genuinely demands it. The cheapest way to test that judgement is empirical: run your math on a live platform for a week and see what you would actually be building.