A gambling app development agency checklist should test evidence, not sales claims. A suitable delivery partner must be able to show who will build and maintain the product, how sensitive functions are tested, which third parties it depends on, and what the buyer receives when the contract ends.
Quick answer: Request a named delivery team, a system-boundary diagram, a sample of redacted engineering evidence, security and QA test records, a reference contact, a proposed responsibility matrix, and draft handover terms. Verify mandatory legal and security gates before comparing scored bids.
This checklist is for procurement leads, CTOs and licensed operators buying implementation services. It does not decide between white-label and custom software; see the sourcing comparison. It also does not estimate build cost; use the cost estimation framework for that separate decision.
What to Request Before Shortlisting
Send all bidders the same brief. Name the intended markets, operator entity, planned app platforms, product boundaries, existing suppliers, required integrations, expected internal ownership and the date by which evidence is needed.
Ask for an evidence pack, with commercially sensitive details redacted where necessary:
- Delivery organization: named technical lead, actual delivery locations, subcontractors, allocation assumptions and a replacement process for key staff.
- Comparable work: two references with the agency’s precise role, delivery dates, changes in scope and who operated the product afterward.
- Architecture sample: current or anonymized component and data-flow diagrams showing app, APIs, payments, identity, location, game suppliers and external SDK boundaries.
- Engineering sample: redacted pull request, code-review policy, CI pipeline run, release checklist and defect-to-fix history. Ask for a live walkthrough where possible.
- Risk documents: security test summary, unresolved findings, continuity plan, dependency inventory and proposed incident escalation contacts.
For each item, record received date, scope covered, verification owner, gaps and follow-up. A missing artifact is not automatically proof of poor practice, but it should not be scored as verified evidence.
Check Engineering Capability and Supplier Boundaries
A mobile agency may build a front end while a platform vendor controls accounts, wallet logic or game services. Ask the bidder to draw the boundary and identify who approves every production change. For each critical journey—registration, age and identity checks, geolocation, deposit, play, withdrawal, limits and self-exclusion—request a named system owner and a failure-handling path.
Use a technical interview to inspect one real engineering decision. For example: What happens when a user starts a withdrawal, the app loses connectivity, and the payment provider times out? A credible answer identifies authoritative states, idempotency, reconciliation and escalation owners rather than promising that the mobile app will retry indefinitely.
In Great Britain, an agency’s exact activities may affect whether a gambling software licence is needed. The UK Gambling Commission’s software guidance distinguishes software manufacture, supply, installation and adaptation, and also distinguishes software licensing from operating licences. Have counsel assess the actual contract and market; do not assume that every design studio needs the same licence or that the operator’s licence automatically covers its suppliers.
| Technical question | Evidence worth requesting | Warning sign |
|---|---|---|
| Who owns each critical API and data store? | Component map with operator, agency and platform owners | “Our team handles everything” without boundaries |
| How are money state changes reconciled? | Redacted state diagram and failure test | Client-side balance treated as authoritative |
| Can changes be released independently? | Branch, CI, environment and approval walkthrough | Unclear production access and deployment authority |
| What depends on subcontractors? | Named subcontractor register and escalation route | Critical work delegated without buyer visibility |
Verify Security and Privacy with Testable Artifacts
Ask how the agency protects source repositories, build pipelines, signing credentials, mobile secrets, privileged access and personal data in non-production environments. Request a vulnerability remediation policy and examples of how a finding was tracked through retest.
NIST’s Secure Software Development Framework, SP 800-218, offers a common vocabulary for secure development and supplier conversations. For the mobile client, map an assessment to OWASP MASVS control groups such as storage, authentication, network, platform and privacy. OWASP notes that MASVS covers client-side security; backend services need a separate review. Ask for test scope, date, tester independence, open findings and retest proof—not merely a scanner screenshot.
For privacy, request the inventory of external SDKs and data recipients, the purposes of processing, an approval path for new SDKs and the buyer’s access to audit evidence. The detailed governance of these flows belongs in the SDK privacy audit, not in an agency ranking score alone.
Mandatory gate: no bidder progresses to a production-facing contract while there is an unresolved, unowned critical exposure affecting player identity, restricted accounts or financial integrity. The gate must be reviewed by the buyer’s security and compliance owners; the exact trigger criteria are organization-specific.
Assess QA, Accessibility and Release Discipline
Ask the agency to demonstrate how it turns requirements into tests, how defects are triaged and how release acceptance works. Request an anonymized regression report, device/OS selection rationale, automated test coverage summary and a trace from defect to verified fix. Test evidence should include interruptions and failed external services, not only happy-path screens.
Look for explicit test ownership around self-exclusion, limits, location restrictions, payment reconciliation and account recovery. The agency may execute these tests, but the operator and relevant licensed suppliers should approve the requirements and acceptance criteria. Do not let a vendor’s demonstration replace a formal control-owner sign-off.
For accessibility, ask to see keyboard and screen-reader test notes, focus order, scaling and text contrast results, plus named remediation owners. W3C’s mobile accessibility guidance explains how existing accessibility standards apply to mobile experiences; a blanket claim of “WCAG-compliant” without tested scope is not sufficient procurement evidence.
| Test area | Interview prompt | Acceptable artifact |
|---|---|---|
| External failure | How do you simulate payment and location service faults? | Test cases with expected and observed states |
| Player protection | Who signs off on limit and exclusion scenarios? | Owner-approved test trace and defect log |
| Accessibility | Which assistive technologies and flows were checked? | Dated manual findings plus retest results |
| Release process | Who can stop distribution and trigger response? | Release RACI, monitoring handoff and stop criteria |
Put IP, Handover and Support in the Contract
Technical strength is not enough if the buyer cannot maintain the product. Negotiate rights and operational access asset by asset: new code, pre-existing modules, third-party licenses, designs, build scripts, infrastructure definitions, configuration, documentation, test suites and data exports. State exactly what is assigned, licensed, excluded or available only while the contract remains active.
Schedule an exit rehearsal before final acceptance: the buyer or a designated replacement team should be able to clone the permitted repositories, reproduce a build in an approved environment, locate documentation and identify missing supplier credentials or approvals. Do not copy live signing keys or production personal data into a handover pack.
Specify support beyond vague “maintenance included” language. Name support hours and time zones, severity definitions, acknowledgement and recovery targets, incident command, post-incident evidence, security patch process, subcontractor escalation and the commercial treatment of work outside scope.
In regulated markets, contracts also need a clear allocation of audit cooperation and evidence access. For example, the UKGC security audit advice says operators must assess assurance from relevant third parties; outsourcing does not remove the operator’s responsibility. Review market-specific language with qualified counsel.
Before signing, ask: Who owns the build if a developer leaves tomorrow? Can the buyer prove an independent build? What is the offboarding timeframe? Who pays for fixing pre-existing critical defects? Which records must be retained under applicable law?
Use a Weighted RFP Scorecard with Hard Gates
Score only what the bidder has demonstrated. The following illustrative procurement weights total 100% and should be adjusted to your risk profile.
| Dimension | Example weight | What earns a strong score |
|---|---|---|
| Team and comparable delivery | 15% | Named people, availability and reference verification |
| Architecture and integrations | 20% | Clear component ownership and failure-mode demonstration |
| Security and privacy | 20% | Scoped tests, remediation records and data-flow controls |
| QA and accessibility | 15% | Traceability, defect evidence and manual validation |
| Handover and IP clarity | 15% | Reproducible builds, rights schedule and exit rehearsal |
| Operations and support | 15% | Measurable SLAs, escalation rota and incident cooperation |
Rate evidence from 0 (none) to 4 (independently demonstrated), using 1–3 for increasing completeness. Weighted score = Σ(weight × verified rating ÷ 4). In the downloadable workbook, ratings and verification are editable; hard gates begin Pending and the decision starts at HOLD. A score cannot override a failed licensing assessment, unacceptable critical vulnerability, missing lawful data-processing terms or absent exit rights. A threshold such as 75/100 is an internal example, not a benchmark or certification.
Use a three-stage decision: first, counsel/security checks the hard gates; second, cross-functional reviewers score evidence independently; third, procurement documents assumptions, clarifications and contractual conditions. Reference calls should confirm both a difficult delivery moment and how the agency responded.
RFP Questions to Send to Each Finalist
A practical casino app developer RFP should require written answers and an artifact reference for each question:
- Which work is done by employees versus subcontractors, and who approves personnel changes?
- Which components, services, data stores and production controls remain outside your responsibility?
- Show one redacted CI run, security finding with retest, regression trace and accessibility issue resolution.
- Which third parties could delay integration, release or restoration? Who contacts them outside business hours?
- What access, documents, code and rights transfer at each milestone and on termination?
- Describe a real delivery problem and introduce a reference who can verify your role and resolution.
Give bidders a secure channel for evidence. Permit redaction and independent walkthroughs where a document would expose another client’s confidential data.
Editable resources: agency due-diligence scorecard (Excel); RFP questions (CSV). These templates contain example inputs and require project-specific review before operational use.
Frequently Asked Questions
What should I check first when hiring a gambling app development agency?
Check whether the agency can legally perform its proposed work in the target market, who owns the critical services and what production-security evidence it can provide. Obtain qualified market-specific advice where licensing scope is unclear.
Is an ISO certificate enough to approve a gambling software vendor?
No. Confirm its validity, scope and relevance, then examine actual controls, third-party boundaries, test results, open findings and required operator-side assurance.
How do I compare two agencies with different technical stacks?
Score verifiable outcomes—team capacity, interface ownership, security process, QA evidence, handover and support—against the same RFP. Keep stack preference separate unless a documented architecture constraint requires it.
What is a deal-breaker in gambling app vendor due diligence?
A failed mandatory legal or security gate, inability to establish responsibility for player-protection and financial controls, or contract terms that prevent required assurance and practical continuity should block progression until resolved.
Procurement takeaway: choose the partner whose claims survive inspection and whose contract leaves the operator able to govern the product. Download the evidence-led RFP workbook to record findings, compare finalists and preserve a defensible selection decision.
