Choosing a casino software provider is one of the highest-stakes procurement decisions in iGaming. The decision shapes commercial economics for 5-10 years, dictates regulatory exposure, and constrains every product strategy that follows. Operators who run the selection as an unstructured vendor comparison consistently end up locked into the wrong platform. This guide is the structured seven-stage process Jadex sees produce better outcomes.

Why a structured selection process matters

Casino software provider selection is unlike most software procurement. The contract typically locks the operator in for 3-5 years minimum. The platform constrains every subsequent product decision. Migration costs are substantial. Revenue share at scale runs into the millions annually. Getting this decision wrong is one of the most expensive mistakes an operator can make.

Operators who treat selection as “compare three vendors and pick the cheapest” consistently regret it. Operators who run a structured process — even if the process takes four months — consistently land on the right vendor for their commercial profile. The structure exists to surface the right questions at the right time, force decisions about internal requirements before being influenced by vendor pitches, and verify claims before they become contractual.

The build vs buy decision precedes this process. If you haven’t yet decided whether to build custom or licence a platform, the framework for that sits in our casino platform build vs buy guide. This guide assumes the operator has decided to licence a platform and is now selecting the vendor.

Stage 1: Internal requirements scoping

The most common reason selection processes produce poor outcomes is that operators start evaluating vendors before clarifying what they actually need. The result is requirements drift — what looked important in early demos becomes irrelevant by Stage 4, and what actually mattered surfaces only after contract signing.

Internal requirements scoping covers six dimensions:

Commercial scope. Which jurisdictions? Which product verticals (casino, sportsbook, poker, bingo, live)? Single brand or multi-brand? Projected GGY over 3-5 years? Existing player base or greenfield launch?

Regulatory scope. Which licences held or in application? UKGC? MGA? Gibraltar GGC? Regulated US states? LatAm markets? Each carries different platform compliance requirements.

Product differentiation strategy. Where will the operator compete? Brand and acquisition? Product experience? VIP service? Crypto-native? The answer determines how much platform customisation matters.

Technical scope. Existing systems requiring integration? CRM stack? Payment providers? KYC vendors? Game aggregator preferences? Reporting and BI tooling?

Internal capability. Does the operator have engineering capability to operate, customise, and maintain a platform? Or does the platform need to be operationally turnkey?

Commercial constraints. Budget for setup fees? Acceptable revenue share range? Time-to-market constraint? Funding round dependencies?

The output of Stage 1 is a written requirements document — typically 8-15 pages — that anchors every subsequent stage. Vendors will try to redefine requirements during their pitches. A written document gives the operator a stable reference point to evaluate against.

Stage 2: Market mapping

The iGaming platform market splits into three structural categories. Operators who try to compare across categories typically end up confused because the categories solve different problems.

White-label / turnkey platforms. Full operational platforms with licensing, payments, KYC, games, CRM, and back-office bundled. Examples: SoftSwiss, BetConstruct, Aspire Global, Pragmatic Solutions. Best for: operators wanting fast launch, minimal engineering overhead, willing to accept revenue share.

Modular platforms. Component-based platforms where operators select and combine modules. More flexibility than white-label, more integration complexity. Examples: EveryMatrix, GiG, Bede Gaming, White Hat Gaming. Best for: operators wanting platform customisation without full custom build, with some engineering capability.

Custom development partners. Bespoke platform builds, operator-owned. Higher upfront investment, no ongoing revenue share, full control. Examples: Bede Gaming (also offers custom), CrustLab, Andersen, Jadex Consulting. Best for: operators at sufficient scale where revenue share becomes material, or with product differentiation strategies that require platform-layer flexibility.

Mapping the market against the internal requirements document narrows the candidate pool dramatically. An operator targeting UK + Ontario + Brazil with multi-brand strategy and £50M+ projected GGY rules out single-jurisdiction white-labels before Stage 3 begins.

Stage 3: Long list compilation

The long list is the initial candidate pool — typically 8-12 vendors who pass the basic fit criteria from Stage 2. The aim is breadth, not depth. Better to include a borderline candidate at this stage than discover after Stage 5 that the best fit wasn’t on the list.

Long list sources include industry analyst reports (H2 Gambling Capital, EGR supplier directories), peer recommendations from other operators, regulatory filings showing which platforms are licensed in target jurisdictions, and conference attendee lists from SBC Events and ICE.

Each long-list candidate needs basic fitness verified before progressing: regulatory licences held, jurisdictional coverage, product vertical support, public commercial model (revenue share vs flat fee), and any obvious red flags from public information.

Stage 4: RFP issuance

The RFP (Request for Proposal) is the formal information request sent to long-listed vendors. It’s the operator’s chance to gather standardised information for comparison, and it’s the vendor’s first chance to demonstrate seriousness.

A well-designed RFP covers:

• Vendor company information, ownership, financial position
• Platform technical architecture and integration capabilities
• Regulatory compliance posture and certification status
• Commercial model and indicative pricing for the operator’s scope
• Timeline and implementation methodology
• Reference customers in similar profile to the operator
• Support and SLA structure
• Roadmap visibility and influence

Vendors who respond fully and on time signal operational seriousness. Vendors who respond with marketing material rather than the requested specifics are a soft red flag. Vendors who don’t respond at all (typically 1-3 from a long list of 10) are filtering themselves out, which is useful.

A separate guide on RFP structure and templates is forthcoming in this cluster.

Stage 5: Shortlist construction

The shortlist filters the long list to 3-5 vendors for deep evaluation. The shortlist size matters — fewer than 3 risks insufficient comparison, more than 5 dilutes the depth of evaluation each vendor receives.

Shortlist criteria typically combine:

• RFP response quality and completeness
• Commercial fit against the operator’s budget and revenue model
• Technical fit against the integration scope
• Regulatory fit against the jurisdiction scope
• Reference customer profile similarity
• Cultural fit signals from initial interactions

A scoring rubric helps make the shortlist defensible internally — particularly important when the decision involves multiple stakeholders or board approval. The criteria carry different weights for different operators; an operator with a hard time-to-market constraint weights implementation timeline higher than one with no fixed launch date.

Stage 6: Due diligence

Due diligence is verification, not evaluation. By Stage 6, the shortlisted vendors have all passed basic fit. Due diligence verifies their claims, surfaces commercial and operational risks, and identifies which vendor the operator can confidently sign a multi-year contract with.

Due diligence covers four domains:

Technical due diligence. Platform architecture review, integration testing, security audit, performance verification under load, code quality assessment where access is granted. Often involves a technical team visit to the vendor’s offices and review of their development practices.

Regulatory due diligence. Verification of all claimed regulatory certifications, review of compliance audit history, assessment of regulatory change management practices. Critical for operators in regulated jurisdictions where platform compliance failures create direct licensing risk.

Financial due diligence. Vendor financial health, ownership stability, customer concentration risk, contract terms (early termination, IP ownership, data portability).

Reference verification. Direct conversations with three to five reference customers, ideally including at least one in similar commercial profile and one who has migrated away from the vendor (most vendors will provide only current customers, but operators can find migrated-away references through industry networks).

The detailed approach to each is covered in our iGaming platform vendor due diligence guide.

Stage 7: Negotiation and contracting

By Stage 7, the operator has typically narrowed to one preferred vendor with one or two backups. Negotiation covers commercial terms, SLA structure, IP and data ownership, contract length and exit terms, performance penalties, and roadmap influence.

Key contract provisions that operators frequently under-negotiate:

• Data portability rights at contract end
• Source code escrow for business continuity
• Service level agreements with meaningful penalties (not just credits against future fees)
• Roadmap influence and customisation rights
• Regulatory change management responsibilities
• Multi-jurisdiction expansion terms
• Early termination provisions and migration assistance

Operators who run Stages 1-6 well and then under-negotiate at Stage 7 end up with the right vendor on the wrong terms. The negotiation phase typically takes 4-8 weeks for a serious contract. Compressing it materially undermines the value of everything that came before.

How long the full process takes

A well-run selection process from Stage 1 to signed contract takes 4-6 months for most mid-market operators, 6-9 months for enterprise operators with multiple stakeholders, and 3-4 months for smaller operators with constrained scope.

The pressure to compress comes from commercial urgency — funding rounds, market windows, competitive pressure. Operators who compress to 8-10 weeks consistently produce worse outcomes than operators who run the full process. The cost of a bad platform decision over 5 years dwarfs the cost of 3 extra months of process.

FAQ

What are the key stages in selecting a casino software provider?

The seven stages are: internal requirements scoping, market mapping, long list compilation, RFP issuance, shortlist construction, due diligence, and negotiation. Each stage produces outputs that feed the next. A well-run process takes 4-6 months from kickoff to signed contract for most mid-market operators.

How long should a casino software provider selection take?

A structured selection process typically takes 4-6 months from internal requirements scoping to contract signing. Enterprise operators with multiple stakeholders often take 6-9 months. Compressing below 3 months consistently produces poor outcomes because due diligence is necessarily abbreviated.

What are the main categories of casino platform vendors?

The iGaming platform market splits into three structural categories: white-label / turnkey platforms (SoftSwiss, BetConstruct, Aspire Global), modular platforms (EveryMatrix, GiG, Bede Gaming, White Hat Gaming), and custom development partners (CrustLab, Andersen, Jadex Consulting). Each category suits a different operator profile, and comparing across categories typically introduces confusion rather than clarity.

What should be included in an RFP for a casino software provider?

A casino software RFP should request company information and financial position, platform technical architecture, regulatory compliance posture, commercial model with indicative pricing, implementation timeline and methodology, comparable reference customers, support and SLA structure, and roadmap visibility. The RFP’s purpose is to gather standardised information for comparison and to surface vendors who respond with marketing material rather than specifics.

What is the most common mistake operators make when choosing a casino software provider?

The most common mistake is evaluating vendors before clarifying internal requirements. Operators who skip Stage 1 (internal requirements scoping) typically experience requirements drift during the selection process and end up signing with the vendor who pitched best rather than the vendor who fits best. The second most common mistake is under-investing in due diligence (Stage 6), where verification of vendor claims often surfaces risks that change the recommendation.

Next step

If you’re running a casino software provider selection and want technical, regulatory, or commercial input at any stage, speak to Jadex’s iGaming engineering team. We’ve supported operators through requirements scoping, RFP construction, technical due diligence, and contract negotiation across multiple platform vendor evaluations. See our full iGaming development capability.