The Slot Launch QA Checklist: 40 Checks Before Go-Live

Integration · 2026-07-16 · 9 min read · By CROCO Games

A practical 40-point pre-launch checklist for operators integrating a new slot: math and config, platform behaviour, mobile UX, compliance, and lobby readiness — each with a verification method.

Most slot launch incidents are not exotic: a wrong RTP variant in one market, a bonus round that loses state on reconnect, a thumbnail that never got localised, a demo mode pointing at real money. All of them are catchable in an afternoon with a checklist — and almost nobody runs one, because launch day is busy and the aggregator said everything was fine. Here are the 40 checks we recommend operators run before any new title goes live, grouped into five blocks of eight. Each check says what to verify and how. Adapt ruthlessly; delete nothing until you have been burned by the thing it catches.

Block A — Math and configuration (checks 1–8)

  1. RTP variant per market. Confirm the deployed variant in each jurisdiction matches your commercial and regulatory intent. Verify in the game's paytable/info screen on production, per market — not in the aggregator back office alone; config drift between the two is a classic incident.
  2. Stake limits. Min/max bet and the stake ladder match your market config and player expectations; check the extremes actually spin.
  3. Currency display. Correct currency, correct formatting, correct conversion on non-base currencies — including inside the paytable, where hardcoded € has embarrassed many launches.
  4. Paytable arithmetic. Spot-check five paytable entries against the game-sheet specs; wrong-variant paytables surface here first.
  5. Feature parameters. Bonus-buy price, feature bet multipliers, jackpot tier seeds — every configurable number against the spec sheet.
  6. Max-win cap. The advertised cap matches the deployed config, and win-capping behaviour at the cap is correct (locked reels, capped counter, correct message).
  7. Jackpot wiring (if applicable). Counters increment, display the right pool, and tier logic matches contract — local vs network pools especially.
  8. Demo mode. Fun-play exists where legal, is clearly labelled, uses no real wallet, and is disabled where prohibited. Both failure directions are compliance incidents.

Block B — Platform behaviour (checks 9–16)

  1. Wallet round-trip. Bet debit and win credit reconcile exactly — run a scripted session and diff game history against wallet transactions to the cent.
  2. Disconnect recovery. Kill the connection mid-spin and mid-bonus; the session must resume at the identical state with balance intact. The single most common live-issue source on new games.
  3. Round history. Every round appears with correct stake, result and feature detail; replay works where offered.
  4. Concurrent-session policy. Two devices, one account: whatever your policy (block, take-over, allow), verify the game enforces it without balance corruption.
  5. Latency degradation. Throttle to 3G speeds: the game must stay playable and, above all, never mis-state balance during slow wallet calls.
  6. Error handling. Simulate wallet timeouts and malformed responses; the game should fail into a clear resumable state, never a spinning-forever screen.
  7. Session limits integration. Your platform's reality checks, loss limits and session clocks fire correctly in-game — overlay renders, play pauses, regulatory events log.
  8. Load sanity. If launch marketing will spike traffic, confirm the provider/aggregator has seen your projected concurrency; ask the question in writing.

Block C — UX and mobile (checks 17–24)

  1. Portrait and landscape. Both orientations render correctly on small phones — controls reachable, symbols legible, no clipped UI at 320px widths.
  2. Touch targets. Spin, stake and menu controls meet minimum touch sizes; no accidental-bet layouts (stake stepper adjacent to spin is the classic).
  3. Load time. First-load and cached-load times on a mid-range phone over 4G; a lobby that loads in 2s feeding a game that loads in 20 leaks players at the door.
  4. Autoplay compliance. Autoplay limits, loss-bound settings and forced-stop behaviour per jurisdiction (some markets prohibit autoplay entirely — verify it is absent there).
  5. Sound defaults. Muted-by-default policies honoured; unmute persists across sessions; no audio blast on load.
  6. In-game info. Rules, paytable and RTP screen open, are localised, and match the deployed variant — the info screen is a regulatory document, not a decoration.
  7. Localisation sweep. Every visible string in each launch language; machine-translated bonus rules and truncated German compounds are perennial offenders.
  8. Interrupted-feature UX. Enter a bonus, close the browser, return: the re-entry experience should be obvious to a confused player, not just technically correct.

Block D — Compliance and responsible gambling (checks 25–32)

  1. Certification coverage. The exact build hash/version is certified for each launch jurisdiction; keep the certificate references on file for audit.
  2. Market restrictions. Geo-blocking matches the certified-market list; test from a blocked geo, not just an allowed one.
  3. Advertised claims. Every number in your promo copy (max win, RTP, feature frequency) matches the deployed config — marketing-vs-config drift is a regulatory complaint generator.
  4. RG tool visibility. Deposit limits, self-exclusion and reality checks reachable from within the game session per local rules.
  5. Age/ID gating. The game is unreachable by unverified accounts where verification is required pre-play.
  6. Bonus terms alignment. If launch promos attach free spins, wagering terms, game weighting and max-conversion caps are configured and displayed correctly.
  7. Regulatory reporting. Rounds flow into your jurisdiction reporting (where required) with correct game identifiers — a silent mapping failure here surfaces months later in an audit.
  8. Complaint path. Support can see round history and replay for this title; a launch without support tooling turns every player query into an escalation.

Block E — Lobby and marketing readiness (checks 33–40)

  1. Thumbnails. Correct art in every required aspect ratio, localised where your lobby localises, and legible at actual rendered size on a phone.
  2. Metadata. Provider, volatility label, feature tags, RTP shown in the lobby match the deployed reality; wrong volatility labels sabotage segment rows.
  3. Search and filters. The game is findable by name (including plausible misspellings), provider and mechanic filters.
  4. Shelf placement plan. New releases get a median of days, not weeks, of top-shelf attention — across a lobby-tracking dataset of 689 brands, the median game holds a top-10 slot for just 2 days — so the placement plan (which row, which position, how long) should exist before go-live, not after.
  5. Demo link. Marketing demo links point at the production demo, in the right language and currency presentation.
  6. CRM assets. Launch email/push segments defined, creative approved, send scheduled against the placement window — shelf attention and CRM should hit the same week.
  7. Tracking. Game-level analytics events (opens, sessions, feature entries) verified end-to-end in your BI before launch, or you will measure the launch by anecdote.
  8. Rollback plan. A tested procedure to pull the game (lobby removal, active-session handling, player comms) within minutes — the check everyone skips and the one that turns a bad launch into a footnote instead of a week.

Running it without ceremony

Forty checks read heavier than they run: blocks A and E are desk work an analyst clears in an hour with the spec sheet open; blocks B and C are an afternoon with two phones and a throttled connection; block D is mostly confirming standing configuration. The efficient pattern is a shared sheet per launch — check, owner, evidence link, status — reused as a template so launch two costs half of launch one. Providers can shorten the list from their side: CROCO ships per-title game sheets with exact configs, certified-market lists and integration test notes through a single API integration, and our team walks operators through first-launch QA on request via contact.

Frequently asked questions

What should an operator test before launching a new slot? Five areas: math configuration (RTP variant, stakes, paytable), platform behaviour (wallet reconciliation, disconnect recovery), mobile UX (orientations, touch targets, load time), compliance (certification coverage, RG tools, geo-blocking), and lobby readiness (thumbnails, metadata, placement and rollback plans).

What is the most common technical issue at slot launch? State recovery after disconnection — a player dropped mid-bonus must resume exactly where the feature paused. Test it by killing the connection mid-spin and mid-feature; it is the top source of live tickets on new titles.

Who is responsible for slot QA — the provider or the operator? Both, at different layers. The studio certifies math and game behaviour; the aggregator tests integration plumbing; but market configuration, wallet reconciliation, compliance fit and lobby readiness are operator-side and only verifiable in the operator's production environment.

How long does pre-launch QA for one slot take? With a template and per-title game sheets, roughly a day: an hour of desk checks against specs, an afternoon of device and platform testing, and standing compliance confirmations. The first run takes longer; the template pays for itself by the second launch.

Key takeaways