What vendors need to estimate an iGaming build

What is the minimum useful estimate brief?

The minimum useful brief defines the business decision, product boundary, intended markets, delivery responsibilities, external systems, evidence requirements, timeline constraints, and acceptance method. It also separates confirmed facts from assumptions and open questions.

Ask vendors to return a range, confidence level, exclusions, dependencies, and the assumptions that move the range. A single number without those records is difficult to compare or govern.

Do not wait for every question to be resolved before asking for help. If major inputs are unknown, request a bounded discovery estimate with named outputs and a decision point before implementation pricing.

Which product decisions change the estimate?

Describe the users, product type, core journeys, devices, languages, accessibility expectations, content volume, administration needs, reporting, and launch definition. For a game, include the rules, mathematics state, art and audio scope, client and server boundaries, and integration route. For a platform, include accounts, wallet, content, payments, identity, reporting, back office, and data migration.

Prioritize requirements as required for launch, planned later, optional, or explicitly excluded. This prevents every idea from being priced as an immediate dependency.

Which market information is necessary?

Name each intended jurisdiction and the assumed entity, license, product, and supplier roles. Provide known technical standards, testing path, language, currency, payments, identity, reporting, hosting, data, and responsible-gambling requirements.

If those decisions are not confirmed, ask for a paid discovery or separate assumption range. Do not ask a development estimate to stand in for qualified legal or regulatory advice. The United States market hub and Latin America market hub show why broad regions are not sufficient scope.

GLI’s current catalogue separates standards for devices, interactive systems, client-server systems, event wagering, security, and change management, while stating that each jurisdiction sets its own standards. That catalogue is evidence that product and jurisdiction scope matter; it is not evidence of a project’s required standard, certification path, price, or duration.

Which integrations need interface evidence?

For every external system, provide the owner, documentation, sandbox status, authentication method, data flow, rate or availability constraints, required events, error behavior, and contact path. Mark whether the vendor must only integrate, also procure, or operate the service after launch.

Unknown or unavailable interfaces should appear as explicit discovery items, not as invisible fixed-price assumptions.

Which delivery responsibilities belong in the request?

Area	Questions to answer before comparison
Product	Who owns priorities, decisions, content, and acceptance?
Design	What exists, which devices matter, and who approves the system?
Engineering	Who owns architecture, repositories, environments, reviews, and releases?
Quality	Who defines coverage, prepares data, fixes defects, and signs off?
Testing readiness	Which standards, laboratory, evidence, and submission tasks are assumed?
Operations	Who monitors, supports, restores, patches, and responds to incidents?
Handover	Which code, data, accounts, documents, licenses, and training must transfer?

Testing and evidence work should not be hidden inside a generic quality-assurance line. In Great Britain, for example, the UK Gambling Commission’s current remote testing strategy separately addresses testing procedure, annual game testing, live return-to-player monitoring, in-house development and release, annual security audit, and major or minor update scope. Use that as a bounded prompt to identify work and owners for the intended launch—not as a universal testing plan.

What timeline evidence should the vendor receive?

Provide the real deadline, its business reason, fixed external dates, approval windows, internal availability, and dependencies. Ask the vendor to show discovery, design, implementation, integration, evidence preparation, external review, contingency, and launch support separately.

A requested launch date is not evidence that the scope fits. Require each proposal to state the staffing and decisions needed to make its schedule plausible.

How should proposals be normalized?

Give every bidder the same versioned question set and allow written clarifications visible to all participating bidders. Normalize price by scope, assumptions, taxes, licenses, third-party costs, internal work, support, change control, and exit obligations.

Use the development-partner framework to evaluate evidence after the estimates arrive. If Wizards may fit, its game-development services can be evaluated through the same process; Wizards operates GEN.

Frequently asked questions

What do I need before asking for an iGaming development estimate?

At minimum, define the product boundary, intended jurisdictions, launch priorities, delivery roles, known integrations, evidence and testing assumptions, target decision date, and acceptance method. Mark unknowns openly and ask how each one changes the range or confidence.

Can a vendor give a fixed price from an early product idea?

A vendor can quote one, but the number may depend on broad exclusions or assumptions that have not been tested. A short, bounded discovery phase is usually easier to govern when rules, mathematics, integrations, jurisdictions, data migration, acceptance, or evidence ownership remain unresolved.

Why can two vendor estimates differ so much?

They may cover different scope, staffing, delivery models, risk allowances, third-party costs, support, testing, change control, or handover obligations. Normalize each proposal against the same versioned brief before treating price or schedule as comparable.

Should testing and certification costs be included in the development estimate?

They should be visible, whether included, excluded, or supplied by another party. Name the assumed jurisdiction, standard, laboratory or authority where known, test scope, submission owner, remediation allowance, retest assumptions, and which external fees are outside the vendor’s control.