How to choose an iGaming game-development partner

Start with the decision the game must survive

A game-development partner should be evaluated against the exact product, market, integration, and release decision in front of the buyer. A polished reel cannot replace evidence that the team can manage the required mathematics, client, server, integration, quality, documentation, and testing work.

Write a one-page brief before contacting studios. Name the product type, target devices, intended distribution path, target markets, internal owners, known standards, desired launch window, and what already exists.

Ask for evidence at the same level as the work

Evidence should match the responsibility the partner will own. If the supplier will own the release build, ask how it handles source control, acceptance criteria, test evidence, defect severity, dependency updates, and handover. If it will prepare a product for external testing, ask what artifacts it produces and how failed findings return to the delivery backlog.

Decision area	Evidence to request	Warning sign
Product scope	Written inclusions, exclusions, assumptions, and dependencies	A price without a shared scope
Technical delivery	Architecture, environments, review controls, and acceptance process	No named owner for integration risk
Testing readiness	Test plan, evidence pack, defect workflow, and standards mapping	“Certification guaranteed” language
Handover	Repository, build, documentation, access, and support terms	Critical knowledge held by one person
Commercial fit	Milestones, change control, IP terms, and exit path	Ambiguous ownership or open-ended change costs

Separate capability from fit

Capability asks whether a team can perform the work; fit asks whether its operating model suits this project. A large supplier can still be a poor fit for an experimental prototype, while a focused studio can be a poor fit for a multi-market platform program that requires several workstreams and long-term support.

Use the game-development supplier category to structure a shortlist, then carry the same questions into every conversation.

Treat testing and certification as external decisions

No development supplier should imply that it grants certification. Ask which standards and test artifacts the team has worked with, which external laboratory or authority makes the relevant decision, and which assumptions still require confirmation for the intended market.

The UK Gambling Commission’s testing strategy provides one jurisdiction-specific example of why exact scope matters: it identifies game, RNG, platform version, channel, live-like environment, integration, change-control and report fields, and says covered B2C licensees remain responsible for an up-to-date games register even when they use B2B content. Other markets have their own rules. Treat this as a brief-design example, not a global testing checklist or legal conclusion.

For work where Wizards may fit, review its casino game-development pathway alongside other qualified options. The relationship is disclosed because Wizards operates GEN.

Use a weighted scorecard, then investigate the gaps

A scorecard makes trade-offs explicit but does not turn uncertain evidence into fact. Weight only the criteria that affect this project, record the source behind each score, and mark unknowns as unknown rather than awarding a neutral score.

The final recommendation should state why the preferred supplier fits, what could invalidate the choice, and which contract or technical questions remain open. If you want help structuring that brief, submit a project request with or without permission to share it beyond Wizards.

Frequently asked questions

Can a development partner guarantee game certification?

No. A partner can prepare software, mathematics, documentation and test evidence, but the relevant laboratory, regulator or other authority controls its own decision. Treat a guarantee as a warning sign unless the statement precisely describes a separate contractual remedy rather than the certification outcome.

Does a prior test report automatically cover a new platform or channel?

Not necessarily. Changes to the game, RNG, platform, integration, client channel or live environment may change the required scope. Confirm what earlier evidence can be relied on and what must be tested again for the exact build and jurisdiction.

What should a comparable customer reference establish?

It should establish only what the reference can observe: a similar scope, delivery model, integration, market context and support period. A logo or testimonial does not prove the candidate’s performance on this project or disclose the referenced contract, defects or outcome.

Should the lowest quoted price determine the shortlist?

No. Normalize scope first, then compare assumptions, exclusions, dependencies, evidence, internal staffing, change control, support, ownership and exit cost. A low price attached to an incomplete responsibility boundary is not a like-for-like offer.