White Label vs Turnkey vs Custom Lottery Platforms

White Label, Turnkey and custom development describe different ways to deliver a lottery platform, not universal bundles of rights and services. Choose by comparing the operating work, technology decisions and costs your organisation wants to own.

WhiteLotto offers White Label and Turnkey models. Custom development is a third procurement route to compare when your requirements justify a distinct build. Use the same product scope, markets, volumes and service expectations for every proposal so the decision reflects your business rather than a delivery label.

White Label vs Turnkey vs custom: the practical differences

Explore the White Label lottery platform and Turnkey lottery delivery against this matrix. Do not assume that “custom” guarantees code ownership or that “White Label” prevents data access. Those rights come from the agreement.

Start with the operating team you can provide

• Founders and affiliates: compare managed support with the market arrangements, acquisition work and customer responsibilities your team can realistically retain.
• Established operators: identify the existing account, wallet, payment, CRM and reporting systems that a new lottery vertical must connect to.
• Institutional lotteries: begin with procurement, channel architecture, reporting and service-continuity requirements before choosing a delivery model.

A feature list is not an operating model. Name an owner and approver for verification decisions, customer support, payment exceptions, reconciliation, incidents and releases. Document where the platform ends and a managed service or external partner begins.

Compare architecture and data rights separately

Map the player journey first: registration, product choice, purchase, result, settlement and communication. Then identify which system holds each record and which interfaces connect the steps. Use the platform module overview to organise the discussion.

For data, ask about player profiles, transaction history, balance records, consent records and reporting exports where applicable. Review format, frequency, permissions, retained records and exit assistance. A dashboard login is not the same as a workable export; a hosted deployment is not proof that your team owns the underlying software.

For custom development, include documentation, build access, dependencies and future supplier substitution. For White Label and Turnkey, include the configuration boundary, release responsibility and acceptance process for new integrations.

Compare a three-year cost scenario

Use one scenario with the same market, product catalogue, expected volumes, service hours and required integrations. Separate platform-provider charges from payments, verification, game services, acquisition and internal staffing. Include setup, recurring fees, variable charges, development, maintenance and exit costs.

Define the base of any revenue-share calculation, allowed deductions, minimum commitments and treatment of promotions. For a custom build, include ongoing engineering and operational ownership rather than comparing a development quote with a managed-service subscription. The pricing and TCO guide helps make the assumptions visible.

There is no universal profitability crossover. Lower software fees can be offset by greater staffing, integration and maintenance costs. Compare several realistic volumes and the cost of changing requirements.

Compare these cost assumptions with the margin-leakage analysis before choosing which responsibilities to retain or outsource.

Launch speed comes from scope and readiness

A configured platform and a distinct software build have different delivery paths. Both still depend on operating arrangements, brand assets, product decisions, payment acceptance, testing and named approvers. WhiteLotto’s 21-day launch path depends on the agreed scope and prerequisites; it is not a substitute for external approvals.

Use the go-live checklist to define when implementation can start, what blocks launch and who approves the release. Include a cutover and recovery plan when existing players, balances or services are involved.

Ask every supplier to demonstrate the same workflow

Show the required player journey and its operator records, including an exception. Request the module schedule, integration boundary, responsibility matrix, cost assumptions and exit arrangements together. The provider evaluation checklist helps turn these questions into a comparable procurement brief.

Choose the delivery model and component scope separately

Who delivers and operates the platform is a different decision from how much of your existing stack you replace. Evaluate White Label, Turnkey or custom delivery on one axis, and full-platform replacement or selected component integration on another. A delivery label does not establish that a retained account system, wallet or frontend can connect to the proposed solution.

Write down which systems must remain before requesting a proposal. Then ask which boundaries are available, which need scoped work and which are outside the proposed release. Use the platform module overview to describe the required scope and the API integration guide to review the actual connection requirements. Do not compare a complete replacement with an add-on quote as if they delivered the same operating scope.

Assign a system of record to each retained-core boundary

A component approach needs an explicit decision about which system holds the authoritative record and which system may change it. One customer journey can cross several systems without creating several independent versions of the customer or available balance. Prepare account questions with the player account management guide, then request a joined-up demonstration rather than separate module screens.

Name an integration lead who coordinates these boundaries across the retained core, lottery delivery team and external partners. That role does not replace each supplier’s responsibility. Record who investigates a shared incident, who can approve a combined release and who resolves a disagreement about which system owns an exception.

Compare the cost and acceptance of the combined release

Separate a component’s licence or service fee from the work required to connect and maintain it. Add interface changes, test environments, monitoring, cross-supplier support, version compatibility and future exit work to the TCO comparison. Ask who pays for a change in a retained supplier’s interface and who verifies that the integrated customer journey still works after either side releases an update.

Approve the whole journey, not only the delivered component. Include a restriction change, interrupted purchase, reconciliation difference and coordinated recovery in the UAT acceptance plan. Define which parts can be paused or rolled back without abandoning records held by the other systems. Where the required boundary is unavailable, compare the cost of scoped integration work with a broader replacement before selecting the delivery model.

Use the operator readiness library to assemble the brief. Bring your retained systems, proposed component boundaries and release owner to WhiteLotto. CONTACT

Compare player-data access and export rights separately from source-code ownership: they answer different procurement questions. Use the migration checklist to agree export formats, balance reconciliation, accepted entries, unfinished settlements and handover responsibilities. A proposal should state which transition tasks are included, who completes them and how access continues until reconciliation is signed off.

Delivery-model questions

Which model includes a licence?

The label does not establish permission to operate. Confirm entities, markets and responsibilities in the actual operating arrangements.

Which model gives the most control?

Separate control over branding, configuration, operations, data, hosting and source code. Compare the rights you need rather than one generic ownership score.

Is custom development always necessary for integrations?

No. First establish the interfaces and configuration available in the proposed platform. A specific integration may require scoped work in any model.

Can we change models later?

Plan data exports, contract notice, transition assistance and technology handover before signing. A model change depends on those arrangements, not only a new subscription.

Choose the responsibilities you want to own

Bring your target markets, products, operating team, existing systems and intended launch date. We can compare White Label and Turnkey against those requirements and discuss where a different build changes the scope.

CONTACT