Nine questions to ask a game content provider
The due-diligence list we wish operators used on us. Most of it is unglamorous — deployment topology, rollback semantics, who owns the RTP — and all of it predicts how the partnership goes.
Operators tend to evaluate content on the wrong axis. The demo looks good, the revenue share sounds fine, and the questions that actually determine whether you regret the deal in month four never come up. Here is the list we would use.
1. Whose code is it?
A surprising share of "in-house" catalogues are white-labelled from a third studio, which means a second revenue split you are indirectly paying for, and a support chain with an extra hop in it. Ask who wrote the game. Ask what happens to your integration if that relationship ends.
2. How are games deployed?
If every title runs from one application, one title's traffic spike is every title's problem. Ask whether games are deployed independently, and what the blast radius of a single failing game is. This is not theoretical — crash-style games have synchronised load spikes at round boundaries, and they will find any shared bottleneck you have.
3. What happens to an unsettled round?
Every provider has a story for the happy path. Ask what happens when their settlement call to your wallet fails permanently. If the answer is not "we roll back the debit automatically and you can reconcile it from a report," you will be doing manual ledger repair at some point.
4. Who controls the RTP?
Ask whether you can set it, at what granularity, and whether changing it needs a deployment. Per-game and per-currency control that takes effect without a release is the difference between running promotions and filing a ticket.
5. How long does integration actually take?
Ask for the number of endpoints you implement, and ask to see the certification suite before signing. A provider confident in their integration will hand you sandbox credentials during the evaluation, not after the contract. If sandbox access is gated behind signature, that tells you something.
6. What player data do they want?
Every field they ask for is a copy of your customer data in someone else's database. Ask for the full list, then ask why each one is needed. Real usernames for a live-bets feed can be pseudonyms. Emails for notifications can be your job. IP addresses are almost never necessary and are among the most sensitive things you can hand over.
7. Is the fairness claim verifiable without their tools?
If checking a round requires the provider's own verifier, you have not removed trust — you have relocated it. Ask for the derivation function and confirm your own engineer can reimplement it in an afternoon.
8. What does mobile mean here?
Ask whether mobile is the same build or a separate SKU, and whether it runs in a webview inside your app. A responsive build costs you nothing extra and works everywhere. A separate mobile licence is a pricing structure wearing a technical costume.
9. Who will you actually talk to?
The most reliable predictor of how an integration goes is whether you get a shared channel with the engineers or a support portal with an SLA. Ticket queues are how vendors scale support; they are also how a two-hour question becomes a three-day one. Ask specifically: during integration, who is in the channel, and are they the people who wrote the game?
None of these are hard questions, and none of them are about the games looking good. That is the point. The demo is the easiest thing for a provider to get right, and the least predictive of the next twelve months.