Buying iGaming SaaS As-Is: What Belongs in the Scope

Here is a sentence that should make every platform buyer pause: "yes, that's included." Included in what, exactly? In the current release you tested? In a configuration the supplier will apply? In a modification someone will build later? In a verbal assurance from a sales engineer who will not be in the room when the dispute arrives? Buying iGaming SaaS as-is is a perfectly sound way to acquire a platform — provided the written scope is treated as the product's other half. When the scope is vague, as-is becomes a loophole.

Buying software as-is means the current product is the baseline of your evaluation and of the agreement. That is a strength, not a caveat: you can test what exists, today, and hold the supplier to demonstrable behaviour. But it makes the written scope unusually important, because your team needs to know precisely what it can use on day one and which requested changes sit outside the delivered product. The phrase "as-is" should open a clear conversation about the release, the included services, and the agreement. It should never substitute for those details.

Record exactly what you evaluated

Start the scope document with evidence, not intentions. Identify the release and the environment used for the walkthrough — version, date, and who demonstrated what. Attach a requirement list that separates demonstrated behaviour from unanswered questions. This sounds bureaucratic until the first disagreement, at which point it becomes the only thing that matters.

Capture the evidence in a consistent format, and the habit will carry your team through every later dispute:

• Version and build: The release identifier of what you were shown, plus the environment type (demo, sandbox, production).
• Date and demonstrator: When you saw it and who showed it — useful when a roadmap promise is later reinterpreted.
• Requirement state: For each item, "demonstrated" or "open question." Never let an open question masquerade as a demonstrated capability in your own documents.
• Reference points: A screenshot or a named screen, so a later reviewer can re-find the behaviour without relying on memory.

A sales presentation can explain a product. It cannot commit a supplier. The written scope needs to say what the supplier is committing to provide, in terms specific enough that a stranger could check whether it was delivered. If a capability was shown in the demo, reference the demonstration. If it was described but not shown, record it as unverified. If it was promised for a future release, record it as a roadmap item with no delivery commitment — because that is what it is.

The casino platform demo checklist and the sportsbook platform demo checklist are built to capture this evidence during evaluation sessions, while the product is in front of you.

Classify every requirement — no single "yes" column

The most common scope failure is a requirements spreadsheet with one column for the supplier's answer, filled with "yes." A yes can mean five different things, and four of them involve work nobody has scoped. Use a short classification instead:

Class	What it means	What the scope must record
Standard	Present in the current release, demonstrable today	Version and date demonstrated; where it was seen
Configuration	Achievable with existing settings, no new code	Who applies it, when, and how it is verified
Modification	New work outside the current product	Separate scope: outcome, acceptance criteria, owner, maintenance
Third-party dependency	Relies on an external provider the supplier does not control	The dependency named, with its own owner and evidence
Unavailable	Not offered and not committed	Recorded as unavailable — so nobody plans around it

Every requirement in your evaluation gets one of these labels. The classification is the scope. If you are still shaping the underlying requirements, our article on iGaming SaaS vs custom development covers how to identify which requirements are actually mandatory.

Applying the labels is quick once the product literature is set aside. Take a shared casino/sportsbook wallet as an example — using your own requirement phrasing: the wallet ledger itself may be standard if it was demonstrated; "deposit limits visible to a compliance role" may be configuration; a reversal workflow with dual approval may be a modification; a specific payment method may be a third-party dependency; and a proprietary cross-brand points scheme may be unavailable on the current product. Same product, five answers — and now each one enters the scope with the correct treatment. Our deeper note on shared wallet behaviour shows the questions that drive that classification.

Write modifications as outcomes, not ideas

A modification request fails in one of two ways: it is too vague to estimate, or it prescribes a solution instead of a result. Both are avoidable. Write every modification as an outcome a named user can verify.

For a proposed report, define the user, the fields, the filters, the timing, and the expected output format. For a workflow change, describe the starting state and the end state, and specify the exceptions that matter to the operation — the declined payment, the voided bet, the reversed bonus. The exceptions are where estimates are wrong, so they belong in the request.

Vocabulary helps here. "Outcome" means observable behaviour; "solution" means a named technique. Suppliers estimate outcomes honestly and solutions defensively, and defensive estimates are the ones that grow. Specify what the user sees at the end, and let the technical team choose how it happens. That division of labour is also what keeps the modification maintainable — when the implementation belongs to the supplier, so does its support.

A worked example: "improve the back office"

Consider a hypothetical operator — illustrative, not a client story — whose COO writes one line into the scope: "improve the back office for our finance team." No supplier can estimate that responsibly, and any supplier who says yes to it is agreeing to nothing. Sent back for definition, the request becomes: an authorised finance user can filter settled and pending transactions by date range, provider, and status, and export the agreed record set as a file finance can reconcile against provider statements, each morning, without involving the technical team.

Notice also what that rewrite quietly resolves: the reviewer (a finance user), the lifecycle states it must cover (settled and pending), and the failure case (it runs without technical help). Those three details are the difference between an estimate and a quote, between a quote and a dispute, between a dispute and an agreed acceptance. Teams write them in when they treat the scope as the product's other half — and leave them out when they treat it as paperwork.

That version is testable. It still requires technical review — the fields have to exist, the export has to run, the permissions have to work — but both teams can now describe the same test, and both know what "done" means. The distance between those two sentences is the distance between a modification project that closes and one that argues for six months.

Run this rewriting loop on every modification in the scope. If a request cannot be made testable, it goes back to the business owner — the scope is not a parking lot for unresolved internal disagreements.

Agree the boundaries of acceptance

Every modification in the scope needs an acceptance clause that answers five questions before work begins:

• Who is the reviewer? One named person with authority to accept or reject. Not a department.
• Where is it tested? A defined environment, with realistic data, before anything touches production.
• What counts as evidence? The agreed test passing — the export produced, the exception handled — recorded in writing.
• What happens on failure? Rework within scope, at whose cost, within what timeframe. Decide this now, calmly, instead of later, angrily.
• How do new requests enter? A change request process with a change log, so neither team relies on a conversation the other remembers differently.

Then define maintenance, because delivery is the midpoint, not the end. If the custom work depends on a third-party connection, name who handles that provider's future interface changes. Establish how the modification will be tested against later core releases — a modification that is not regression-tested against updates quietly becomes unsupported code while everyone assumes someone else is watching it. Our guide to iGaming platform support SLAs covers the ongoing-service half of this conversation.

One term buyers routinely miss: specify what happens to the modification when you leave. If your export format was custom-built and you later migrate away, who hands you the equivalent data in a usable form? Sequence the exit while the relationship is friendly — it is much harder after.

Separate dependencies from commitments

Every iGaming launch depends on parties the platform supplier does not control: payment providers deciding whether to onboard you, aggregators scheduling your integration, regulators moving at their own pace. These belong in your project plan — with an accountable owner and the evidence required at each step — and explicitly outside the supplier's commitment column.

This distinction protects both sides. A supplier introduction to a payment provider is a courtesy, not an acceptance; the provider's risk team makes its own decision on its own timeline. When a launch date slips because an external approval is still pending, the project plan should already say whose item that was. Our article on why casino platform launches slip maps the dependency chain in more detail, and the launch readiness checklist turns it into a working document.

Do this on the payment side too: record each intended method as a third-party dependency, and after each provider conversation re-classify it. Methods that start as "configured" routinely fall back to "awaiting external approval" — which is exactly where a naive scope breaks the schedule. The payment integration checklist gives every method its dependency row.

Bring a precise list to the first conversation

A good scope is not a negotiating weapon. It is a shared description of reality that lets both teams plan. Record what you saw, classify what you need, write modifications as testable outcomes, and give every dependency an owner. Teams that walk in with that document get their answer in days. Teams that walk in with a one-line email describing a vision still get an answer — but it is a priced guess rather than a commitment, and the difference shows up at the first change request.

ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately. Bring the changes your project needs — a precise list makes the first discussion far more useful, and gives the product team something concrete to assess. The operator scorecard is a good place to draft that list.