How to choose an
iGaming
development company.

BUYER CHECK / 01

Decide whether you need a platform, a component or a team

The phrase iGaming development company covers different purchases. You may need a configured casino platform, a custom application, a sportsbook embedded in an existing site or engineers working on a retained system. Start the brief with that distinction. Otherwise a turnkey quote and a development-team quote can look comparable while allocating entirely different responsibilities to the operator.

Draw the existing operation before the proposed replacement. Mark the frontend, PAM, wallet, cashier, game connections and reporting. For each part, state whether it stays, changes or has not yet been decided. Ask candidates to annotate that same map. A supplier should be able to explain where its work starts and which dependencies it cannot resolve alone.

White-label and turnkey labels need a written definition in the actual proposal. Establish who provides the technology, which business or operating services are included and which decisions remain with the buyer. A custom-build arrangement needs a similarly explicit deliverable and rights schedule. Do not infer licensing, hosting or ownership terms from the delivery label.

Discovery can be the right first purchase when those boundaries are unclear. Commission answers to specific questions, with a finite package and stop conditions. A missing provider agreement or unavailable historical export may prevent implementation. Recording that dependency is useful discovery work when the investigation was commissioned to expose it, even if the next decision is to pause.

BUYER CHECK / 02

Review the proposed delivery team and its evidence

Separate the company's published offering from the people assigned to your work. Ask who will lead architecture, integration and testing, who coordinates with external providers and who can accept a change in scope. Confirm availability and the process for replacing a key specialist. A staffing count cannot establish whether the necessary roles are covered during your project.

Request a relevant walkthrough where disclosure is permitted. Have the supplier explain what it built, what the client retained and which problem limited the design. Ask to see a redacted artifact rather than relying only on a polished presentation. A reference can clarify a past assignment, but its result does not transfer automatically to your providers, data or delivery team.

Use a concrete scenario in the technical discussion. An operator moves new game launches to a replacement provider while an old round remains unsettled. Ask the lead which record identifies the owner of that old round and what evidence the operator can inspect. A good explanation helps you assess the proposal; it remains different evidence from a test of the implemented system.

Confirm subcontractors, working overlap and decision ownership. A nearshore or offshore arrangement can work when the necessary reviews and escalations are covered. An office location is not evidence that the proposed engineer or incident owner will be available. Specify which decisions need a live meeting and which records let another authorized person continue the review.

BUYER CHECK / 03

Map the systems that own account, wallet and payment facts

A visually complete casino interface can leave important accounting boundaries unresolved. Name the system of record for player identity and the authoritative source for wallet effects. Distinguish cash, bonus and other restricted balances where they exist in your actual product. Ask how the platform connects those records to the provider operation and the operator's reporting view.

A seamless-wallet arrangement and a transfer-wallet arrangement create different reconciliation questions. Ask the supplier to show the movement being recorded and which system controls its final status. Include currency, amount representation and identifier scope in the interface discussion. A matching balance on two screens does not explain whether a particular business operation was applied once, twice or not at all.

Payment integration deserves its own state map. Identify the difference between a provider notification, an internal cashier decision and a confirmed wallet effect. Ask who reviews a pending withdrawal and what evidence can change its status. Keep payment-provider access and commercial entitlement visible as dependencies rather than assuming the software supplier can supply them.

PAM, KYC and restriction workflows also need owners. Ask how a pending check or revised account restriction reaches the relevant product and back office. Agree which actor can change the decision and how the revision is reconstructed. The applicable legal and policy requirements belong with qualified operator reviewers for the proposed activity and market; a software feature label does not establish compliance.

CRM, affiliates and reporting can depend on the same business events while interpreting them differently. Request field definitions and a sample trace for the intended report. If finance and support need different views, name their questions before requesting an export. A large number of report screens cannot substitute for a defined source and interpretation of the underlying records.

BUYER CHECK / 04

Ask what happens after the provider response goes missing

List the provider and PSP interfaces in the proposal, including version, environment and connection owner. Catalog access and game launch are different capabilities from settlement handling. Ask which operations a supplied connector actually supports. A sandbox account may permit a useful demonstration without proving production entitlement or covering every provider behavior the operator will need.

For casino integration, request cases for duplicate callbacks, late events and an unavailable response after submission. Keep the original operation identity and ownership records in the discussion. A changed launch route should not silently become the source of authority for an older round. The required production behavior must follow the actual provider contract and the records the implementation retains.

For a sportsbook iframe, separate session recovery from business-operation recovery. A frame can reconnect while the original wallet instruction remains unresolved. Ask how the receiving team identifies the original instruction and determines its effect. Refreshing access should not itself authorize a new financial operation. Request the evidence for the recovery decision rather than accepting a responsive screen as the complete test.

An API integration has different implementation work from an embedded interface. Identify the frontend, authentication and wallet responsibilities that the buyer retains. Ask who owns market or settlement interpretation and which services require a separate trading or data arrangement. Do not treat the presence of an API as evidence that these operating responsibilities disappear.

Give an unknown result an explicit review path. Name the records to inspect, the person who can obtain them and the condition for permitting another action. Missing evidence should remain missing until it is resolved. A timeout alone cannot establish that no effect occurred, while a generic success message may establish less than the complete business outcome the buyer is investigating.

BUYER CHECK / 05

Scope poker, lottery, crypto and game development separately

A broad iGaming brief can hide several independent products. For poker, define the room, game types, tournament requirements and player-pool boundary. Shared liquidity is a particular operating and technical arrangement, not a capability to infer from a poker client demonstration. Ask which component controls seating, game state and settlement in the configuration being offered.

A lottery platform needs a defined ticket and draw boundary. Identify whether the engagement supplies a new engine, connects an existing draw service or adds another product to a retained lottery operation. Request reconciliation evidence for the records the operator must retain. Do not assume the same export or settlement model applies to every lottery product.

For slot development, separate the game client, backend or remote gaming server, mathematics and any certification work. Ask which deliverables include the model and paytable, how versions are identified and which third-party review is within scope. A playable title is useful product evidence while remaining different from proof of every contracted mathematics or release deliverable.

A crypto cashier integration and a crypto-first casino platform also purchase different things. Name the retained account and ledger systems before asking how a transaction becomes an internal credit. Identify who owns confirmation policy, currency conversion and exceptions for the actual integration. Have the appropriate specialists review the applicable requirements; this guide does not prescribe a universal payment policy or market eligibility rule.

BUYER CHECK / 06

Agree on security and acceptance evidence before the demo

Use a versioned acceptance register tied to the proposed delivery boundary. Include ordinary workflows and the failure cases that can change the purchasing decision. Record expected behavior, observed result, responsible reviewer and unresolved evidence separately. A provider's happy-path demonstration can explain its product while leaving the operator's important integration questions unanswered.

Back-office access deserves explicit negative cases. Ask the supplier to show a permitted action and a refused action under different actor or ownership conditions. A successful login demonstrates access to a session; it does not establish authorization for every account, report or administrative operation. OWASP's Authorization Cheat Sheet states:

Use that principle to request evidence for the actual application boundary. Include tenant separation and restricted records when those are part of your scope. Define what must happen when permission evidence is unavailable. The quotation supports the review question; it does not certify any listed company or replace an application-specific security assessment.

Performance claims need a workload. Ask which operations ran, how concurrent work was defined, which environment was used and what latency or failure observations were collected. Keep the test configuration and exclusions with the results. A supplier's published throughput figure may describe a useful system while remaining incomparable with your proposed mix of connections and user activity.

Name the reviewers for security, financial reconciliation and operational acceptance. Some checks require access or authority the delivery team does not possess. Record those dependencies before scheduling the review. A missing approval or unexecuted case remains open; it should not become a passing result merely because another part of the demonstration worked.

No supplier was commissioned or benchmarked for this guide. The cases described here are proposed evidence requests. Your team must choose the relevant tests and acceptance conditions for its actual product. Keep regulatory, certification and jurisdiction-specific decisions with the responsible qualified reviewers instead of reading a company-list position as an approval.

BUYER CHECK / 07

Compare the full scope behind setup fees and recurring charges

Ask every shortlisted supplier to price the same brief revision. Separate setup, custom development, integration and migration from ongoing platform, hosting and support charges. List third-party pass-through costs and buyer obligations next to the corresponding work. An apparently lower total may omit a connection, export exercise or operating service that another proposal includes.

Revenue-share proposals need a defined calculation basis. Identify the relevant measure, period, adjustments and relationship with any minimum fee. A percentage without its denominator is not a comparable price. Ask the supplier to work through the same illustrative month using the terms in its own offer rather than relying on broad industry labels.

Consider a hypothetical schedule with a USD 20,000 setup fee, a USD 3,000 monthly platform fee and a separate USD 800 monthly hosting allowance. The first-year subtotal is USD 65,600: setup plus twelve months of both recurring inputs. This excludes provider charges, taxes, internal labor and any other work not listed. The figures are planning assumptions, not market prices or quotes from the ten companies.

For engineering engagements, connect effort estimates to deliverables and dependencies. Fixed milestones need inspectable acceptance artifacts. Time and materials needs spending authority and review points. Neither commercial format removes the need to identify what happens when provider access is late or the available source data changes the planned implementation.

Define change approval before adding another product, market or interface. A new currency or payment route may affect reconciliation and review scope as well as implementation. Ask who authorizes the change, what must be repriced and which evidence becomes stale. Keep support exclusions visible so a future feature request is not mistaken for included maintenance.

BUYER CHECK / 08

Make migration and exit part of the original purchase

A migration plan should identify what stops admitting new work and what continues completing earlier work. Existing rounds, unsettled bets and pending payments can have different lifetimes from a frontend release. Request an inventory of outstanding obligations and the records needed to keep their ownership intelligible through the change.

Reconcile the agreed opening state before treating the receiving platform as ready. Identify the balance components and the source records used to establish them. A total without its population and exclusions can conceal missing history. Ask the responsible operator reviewers which records they need to explain a later adjustment without reopening the outgoing back office.

Require an export sample that the receiving team can interpret. Field names, identifiers and status meanings belong with the data. Define which historical relationships must survive and which omissions are acceptable for the commissioned scope. Receiving a file does not establish that the buyer can reconstruct the business operation it cares about.

For custom development, list source code, configuration, infrastructure definitions and test materials with their rights and dependencies. For a platform purchase, name the data and configuration the operator can retrieve and the restrictions that apply. Have the appropriate contract reviewer inspect the actual rights schedule. A general ownership claim should not silently include every pre-existing component.

Use a receiving-team exercise to expose missing access or undocumented steps. An authorized engineer might rebuild an agreed component or restore a known configuration in an approved environment. Choose an exercise that fits the purchase. A supplier-operated demonstration and a buyer-performed transfer are different records, even when both show the application working.

BUYER CHECK / 09

Choose the next commitment with open gaps still visible

Before production, agree support coverage, escalation and containment authority. Name the person who can pause an action, restore an accepted configuration or coordinate an incident involving another provider. A shared chat channel is a contact mechanism, not an allocation of that decision. Separate response availability from commitments that depend on another party's access or approval.

The companion worksheet has twelve requirements and starts every one as open. Mark which requirements are mandatory for the commitment you are considering. Use Verified only after the responsible reviewer inspects relevant evidence, and Conflict when observed evidence disagrees with the requirement. Keep the artifact version and next action in your approved workspace.

A mandatory conflict blocks the worksheet's gate summary. An open mandatory requirement keeps it on hold. When every selected mandatory row is verified, only those selected gates are complete; optional gaps remain visible. Selecting no mandatory gates produces an unscoped result. This is a practical review aid, not a validated supplier score or authority to sign a contract.

A limited decision can be useful. You may commission discovery while holding migration, or accept a defined interface while leaving another product outside the engagement. Record the exact next step and the unresolved conditions that could change it. The aim is a purchase your operator and receiving team can describe in the same terms.