White Label, Turnkey or SaaS? Read the Responsibilities

Ask five suppliers what "turnkey" means and you will get five answers. The same goes for "white label" and "SaaS". Suppliers use these labels inconsistently, sometimes deliberately — a label that sounds complete sells better than a scope that is honestly partial. None of the three words settles the questions that actually determine whether your operation works: who operates the business, which permissions and licences apply, what the agreement includes, and how it ends.

The labels are not useless. They are starting points. But a buyer who treats them as specifications will discover the missing items the hard way — usually after signing, when "that's not included" becomes the most repeated phrase in the relationship. The only reliable comparison is a responsibility matrix in writing. This article shows you how to build one.

Separate software from the operation

Every iGaming offer, whatever its label, sits across two distinct layers. Draw them as two lists.

The first list is software: the player interface, the back office, the wallet and ledger, hosting, maintenance, support, release management. The second is the operation: the legal entity, the operating licence or the arrangement that substitutes for one, the permitted markets, the game content contracts, the payment and merchant relationships, the player-facing terms, the AML programme, and the people who staff support, risk and compliance.

Now ask the vendor to go through both lists item by item and mark each as one of three things: supplied (contractually included), coordinated (they arrange it, you contract for it), or yours (untouched by the offer). This is where the labels dissolve. A white label in which the provider's licence and payments are supplied is a categorically different commitment from a white label where those are merely "available through partners". "We can introduce a partner" and "this service is included" are materially different answers — treat them as such.

Regulatory framing matters here. The UK Gambling Commission, for example, states that responsibility for compliance on white-labelled gambling sites remains with the licence holder. That is a British regulatory position, not a description of every commercial package — but it illustrates the principle: wherever a licence is involved, some party carries obligations that cannot be delegated away by a branding agreement. Know which party that is before you compare anything else.

Read the licence and permission question narrowly

Buyers often ask "is the licence included?" when the precise question is narrower: under whose regulatory permission will your players be gambling, in which markets, and with what obligations flowing back to you? An illustrative example (mark it clearly in your notes): two offers, both branded white label. In the first, the provider's licence covers your players, and you supply marketing under the provider's compliance oversight — which caps how you can advertise and often how you can pay out. In the second, the provider supplies software as SaaS, and the licence is your problem entirely. Both are legitimately sold as white label. Only one limits what "your" operation actually controls.

Permissions beyond licensing matter just as much: which markets the offer covers, which payment methods are supported in those markets, and which content is available there. A game supplier's catalogue is not global by default; availability varies by jurisdiction and by the commercial agreements behind it. Ask the vendor to mark each intended market as confirmed, conditional, or out of scope — in writing, attached to the responsibility table.

Watch for scope drift in the commercial offer

Scope drift is the quiet failure mode between demo and signature. The demo shows a working product; the proposal describes a broader arrangement; the contract, if you do not pin it down, commits to something narrower than either. The drift usually hides in three places:

• Coordination versus inclusion. "Payment integration included" can mean the software connects to processors you must contract and qualify for yourself. That is fine — provided your plan accounts for the approval timeline, which is frequently the longest item on the launch critical path.
• Present-tense versus future-tense. Features described in the future tense belong on a roadmap list, not in the scope of supply. Scope what exists; treat the rest as options to be exercised later, not foundations.
• Assumed operating capacity. Managed services around a SaaS core — trading, player support, fraud review — change the shape of the offer completely. If they are included, the staffing and escalation split belongs in the responsibility table like any other item. If they are optional extras, the comparison against DIY-operation must price the staffing honestly on both sides.

The antidote is boring and effective: every scope claim gets a written home in the table or it does not exist. Sales enthusiasm is not a contractual category.

Build the responsibility table

Turn the two lists into a table and make shortlisted suppliers complete it in writing. A fragment looks like this:

Item	Supplier	Operator	Third party	Evidence
Operating licence / regulatory permissions
Game content contracts and availability in target markets
Payment methods, merchant accounts, payout processing
KYC queue, AML monitoring, player disputes
Account restrictions, bonus configuration changes
Data export, historical records, exit handover

Every row gets an accountable party and a supporting document — a contract clause, a scope statement, a service description. Unresolved rows deserve more attention than the package name on the cover page. If a supplier will not complete the table in writing, that is itself a finding. The operator scorecard bakes this structure into a reusable instrument, and the RFP template turns it into questions you can send before any meeting.

Compare control where it actually matters

Branding is the visible part of a white label or SaaS offer, and it absorbs most of the comparison effort. Operational control deserves equal attention, because it defines your daily ceiling:

• Who can change account restrictions? If raising a deposit limit or applying a cooling-off period requires a supplier ticket, your player safety response time is the supplier's queue length.
• Who approves a release? Product updates that change player-facing behaviour without your sign-off are a regulatory and commercial risk in licensed markets.
• Can your staff access the records? Complaints, disputes and regulator requests all resolve to records. View-only access to a subset of logs is not equivalent to investigatory access.
• Who controls the domain and supplier relationships? In tighter white label structures, the domain, the content contracts and even the player database relationship may sit with the provider. That defines your bargaining position at renewal — and, more importantly, at exit.

A package described as turnkey but failing these questions is not turnkey for your purposes. Conversely, a plain SaaS deal in which you hold the licence, contract the content and staff the back office can give you more genuine control than a grandly named alternative. Compare control, not labels. For the pricing and commercial dimension of the same decision, the SaaS versus custom build analysis covers how far an existing product can reasonably be stretched.

Match the label to your constraints, not your preferences

Once the responsibilities are visible, the choice between labels stops being ideological and becomes situational. Three constraints usually decide it:

• Licensing position. If you already hold — or can realistically obtain — an operating licence in your target market, keeping it close is usually worth the overhead, and a SaaS or turnkey supply keeps the regulatory asset in your hands. If licensing is years away, a genuine white label under a provider's licence may be the only viable route, provided you accept its constraints on advertising, payouts and branding.
• Operational staffing. A turnkey or SaaS deal assumes you can run support, KYC review, risk and reconciliation. If you cannot staff that yet, either a fuller white label or a platform-plus-managed-services combination belongs on the shortlist — priced against the cost of hiring, not against the hope of hiring.
• Product distinctiveness. If your proposition depends on workflows an existing product does not provide, the honest question is whether scoped modifications close the gap or whether the gap is structural. An as-is SaaS answer to that is immediate; a custom-build answer is a different project entirely.

An illustrative case: an operator targeting one regulated market, with a licence application in progress and a three-person founding team, compares a white label under a provider's licence against SaaS delivery for the moment their own licence lands. The responsibility table usually resolves it quickly — the white label answers the staffing and timing constraints; the SaaS answers the long-term control concern; and the cheapest honest structure is often white-label-first with a contracted migration path to SaaS, provided the exit rows are negotiated while the provider still wants the deal.

Ask about change — and about exit — before you sign

Two questions are chronically under-asked at the buying stage.

Change. An existing product may fit a standard launch perfectly. A project built around a distinctive workflow — a particular bonus mechanic, a market-specific compliance step, a reporting format your regulator expects — may require work beyond the product as supplied. If so, confirm in writing whether the change affects only your environment or the shared codebase, who maintains it when the core product updates, and what you receive: a defined change with acceptance criteria, or a vague assurance. Our scope and customisation guide explains how to write these down so they survive contract negotiation.

Exit. Request the proposed handover format and scope now, while the supplier is still selling. Player records, wallet ledger history, transaction and bet history — in what formats, over what notice period, with whose assistance? An export right without defined records, access arrangements and a handover process is a right that may prove unusable when you need it. The lawful handling of player information during a transition is a separate legal review; build time for it. The migration checklist shows what a clean exit looks like from the other side, which tells you exactly what to demand contractually.

Choose from evidence, not vocabulary

The conclusion of this process is unglamorous: a completed responsibility table, annotated with evidence, where unresolved rows are marked as such. When two offers sit side by side in that format, the vocabulary falls away and the actual commitments are what remains.

One final habit before you sign: give the completed table to whoever will run the operation, not just whoever owns the budget. A founder reads "player complaints" and assumes a tool. A support lead reads it and asks which party's staff answer players, in which languages, on what response time, with what authority to compensate. Those are the questions the table exists to resolve — and they resolve cheapest before signature.

This is also the honest way to describe our own offer. ScaleBets is a casino and sportsbook SaaS supplied as-is: the product you see in evaluation is the product you receive, and any custom modifications are separately scoped and defined in writing. That model will not suit every project — distinctive operations sometimes need a different answer — but it makes the responsibility table quick to complete, because the boundaries are explicit by design. Review that model against your project, and test it with the same questions you would put to any supplier.