What an iGaming Discovery and Architecture Sprint Should Deliver

The final discovery presentation looks convincing: a platform diagram, a prioritised backlog and a launch date. Then the delivery team asks which supplier assumptions were checked, who approved the scope and what the estimate includes. Nobody can answer without bringing the consultants back into the room. The investigation produced a presentation, but not a usable handover.

A discovery and architecture sprint should leave the business able to make a bounded decision and the receiving team able to act on it. Its outputs must connect the problem, evidence, choices and next commitment. A recommendation to narrow the scope, investigate a dependency or stop can be more useful than an unjustified plan to build.

This guide is for founders, product leaders and technical owners commissioning or accepting such an investigation. It proposes acceptance criteria rather than a universal bundle of documents. The withdrawal-status example is hypothetical; it illustrates how findings should change scope and sequencing, not a result from a client engagement.

Agree what the investigation must let you decide

Write the decision before the workshop agenda. “Design an iGaming platform” is too broad to assess. “Can we add a trustworthy withdrawal-status view to the current product without replacing the payment integration?” names a choice, a boundary and a dependency that can be investigated.

The GOV.UK discovery guide, written for public services, separates understanding the problem from building a service and treats stopping as a valid outcome. A combined commercial discovery and architecture engagement can include agreed technical experiments; those remain investigations, not a production release or an automatic commitment to development.

Agree a short investigation brief with a business decision owner and a technical review owner. It should state:

• Problem and intended benefit: whose difficulty you are addressing, what is known about it and what would count as a useful improvement.
• Scope: products, markets, operator entities, brands, environments and workflows included, plus explicit exclusions.
• Questions and evidence: the assumptions that could change the choice, the access needed to examine them and what cannot be tested.
• Acceptance: who will review the recommendation, which decisions it must support and what happens if essential access or supplier answers are unavailable.

Set the duration from these questions and the people and evidence available. A short calendar window does not justify marking unanswered questions as resolved. The discovery and architecture service describes how to scope the engagement; here the focus is the package you should be able to accept at its end.

Receive findings that can be traced back to evidence

Workshop notes are inputs, not conclusions. The team needs a concise account of what was learned from players, support, operations, product and engineering, including where their accounts conflict. Bring in finance, security, commercial and market specialists when their decisions constrain the investigated workflow.

Use actual material appropriate to the question: approved research, support cases, journey observations, system records, existing decisions, contracts and provider documentation. Minimise sensitive data and keep copies under the organisation’s agreed access and retention arrangements. Neither a workshop invitation nor a sandbox account authorises uncontrolled live testing.

• Finding: state the specific behaviour or constraint, not a broad complaint such as “the platform is unreliable”.
• Evidence: identify the source, date, environment, version and sample, and link to a controlled location where the reviewer can inspect it.
• Status: distinguish directly observed behaviour, a supplier statement, an assumption and an unanswered question.
• Implication: explain which option, requirement or next investigation the finding changes, and name the person responsible for follow-up.

A small sample can expose a problem without establishing its frequency across every player or payment route. If support records do not distinguish status enquiries from genuine processing failures, record that limitation before proposing a success metric. Acceptance should test whether important conclusions have evidence and limits, not whether every note has been transcribed.

The product brief should turn those findings into a bounded outcome, the essential player and operator journeys and the deferred work. Mandatory safeguards and operational completeness must be identified for the actual scope; reducing optional features does not resolve an unanswered requirement.

Ask for maps that expose the real boundaries

Start with a view the business and engineers can discuss together. The C4 system context guidance focuses on the system, its users and directly connected external systems. It does not require low-level technology details at that level.

For an iGaming investigation, label the operator’s platform, staff and player interactions, and the relevant game, payment, identity or reporting dependencies. Show what is owned by the company and what depends on another party. Separate the observed current arrangement from a proposed future one. Date the views and identify the sources behind them.

Then provide only the deeper views needed for the decision: a journey with consequential hand-offs, domain or module ownership, a deployment boundary, or an interface whose behaviour controls the choice. A context diagram cannot prove transaction correctness, tenant isolation or recovery. Those claims need other evidence.

• Journey: include the operator or support action after an automated step stops, not just the successful player path.
• Responsibility: identify who may change an important record or rule and who resolves an ambiguous outcome.
• Interface: record the relevant provider product and version, required data, result meanings and material limits.
• Quality scenario: state an observable requirement, its test conditions and the evidence still needed. Replace “scalable” or “secure” with a specific question the team can examine.

A separate provider dependency list should identify account ownership, commercial eligibility, access, approvals, service expectations and unresolved questions. A supplier logo on a diagram is not confirmation that the required product, market or production account is available. Use the provider evaluation guide when selection is a major part of the decision.

Record choices, alternatives and the limits of experiments

The architecture recommendation should explain why it fits the evidence, the business constraints and the team that will operate it. Compare credible alternatives, including a targeted change, an operational change, integration with an existing service and deferring work where relevant. A preferred technology stack is not an options analysis.

AWS’s guidance on architectural decision records organises significant choices around context, the decision and consequences. Its lifecycle preserves accepted decisions and supersedes them with new records when the choice changes. This is a documentation practice, not a requirement to use AWS infrastructure.

For each consequential choice, include the alternatives considered, evidence used, rationale, trade-offs, unresolved assumptions, approval status and a condition that would trigger reconsideration. Distinguish a proposal from an accepted decision. A review meeting attended by the right people is not proof that all recommendations were approved.

If an experiment informs the recommendation, deliver a short test record: question, environment, configuration, inputs, observation, conclusion and limitations. Include enough instructions and retained evidence for an authorised receiving engineer to repeat or inspect it. State what the experiment does not establish.

For example, a provider sandbox may demonstrate a status lookup without proving production permissions, latency under load or the meaning of every terminal status. A prototype may demonstrate comprehension of a withdrawal timeline without implementing authoritative financial records. Do not place experimental code on the critical path to launch without explicitly planning its production work and acceptance.

Make risks, estimates and sequencing conditional

A useful risk entry is a scenario with a consequence and a response. “Provider risk” is not enough. “The selected account may not expose the status evidence needed by support; this could block the withdrawal view” identifies the dependency. Add evidence status, an owner, a next action and the decision or milestone it affects.

Distinguish a problem already observed from a possible future event, and separate both from a dependency someone else must fulfil. Agree whether the business avoids, reduces, accepts or investigates each material risk, and identify who can make that choice. Operator and qualified specialist input is necessary for market, licensing and player-protection requirements; a technical discovery report does not certify compliance.

Prepare a delivery backlog that a team can refine. For each near-term item, include the intended outcome, boundary, dependencies, acceptance evidence and an owner or responsible team. Group work into complete, reviewable increments rather than a list of disconnected screens. Keep unresolved research work visible instead of disguising it as implementation.

• Engineering estimate: state the scope, assumptions, team capacity and degree of uncertainty. Include integration, testing, data changes, operating tools and handover where they are part of the work.
• External elapsed time: list access, commercial decisions, provider approval or specialist review separately. These waits are not automatically included in developer effort.
• Cost: distinguish development from supplier charges, hosting, transition work, support and ongoing operation. State which amounts remain unconfirmed.
• Sequence: identify what can start now, what waits for evidence and what must be true before the next commitment.

There is no need to attach a confident date to an option whose critical dependency remains unknown. Offer a conditional plan and the next action that would make the forecast more reliable. Explain whether a range represents effort or calendar time; do not present an uncertainty range as a statistical confidence interval without a basis.

Follow one finding through the entire handover

Consider the hypothetical withdrawal-status investigation. The desired improvement is that players and support can understand the progress of a withdrawal without guessing or causing a second payment. The initial request is “add a progress screen”, but the sprint must establish which facts can safely appear there.

• Evidence finding: in the inspected examples, the current interface uses one “pending” label for both internal review and submission to the provider. The small sample does not establish how common each situation is.
• Boundary: keep the existing payment execution flow outside the proposed first increment. The new view reads authorised status evidence; it does not create another payout route or let support rewrite financial outcomes.
• Decision proposal: build an explanatory timeline only for the selected route once the meaning and availability of its status evidence are confirmed. Defer other routes rather than infer their behaviour.
• Dependency: obtain provider confirmation of the relevant status meanings and production access. A successful sandbox lookup leaves those questions open.
• First increment: link an authorised player or support view to the correct withdrawal record, show confirmed milestones and expose an explicit unresolved state where evidence is missing.
• Acceptance evidence: check account access, stale or missing status, conflicting observations, and the support escalation route. For missing or stale evidence, show a dated last observation or an explicit unknown, not an unsupported “paid” status. Confirm that viewing the timeline cannot initiate a payment.
• Next commitment: authorise a bounded implementation stage after the evidence gate, with its operating owner and review point. Keep a launch date conditional on the remaining dependencies.

The package should make each link inspectable: the finding leads to a scope boundary, that boundary shapes the decision, and the decision leads to an implementable item and its acceptance checks. If the provider cannot supply the required evidence, the team can choose another explanatory approach, investigate a different route or stop this option. The discovery result remains useful because it prevents a screen from promising knowledge the platform does not have.

A proposed metric could track status-related support contacts for the selected route after release, provided the team first defines the category and establishes comparable records. Do not invent a baseline, improvement percentage or causal conclusion during discovery. Delivery acceptance and later product success are separate evaluations.

Accept a package the receiving team can actually use

Hold the handover with the people who will own product decisions, implementation and operation. Give them time to read the material first. Ask them to explain the recommendation and trace an important backlog item back to the evidence without relying on the presenter.

For the agreed scope, the following outputs should have a named maintainer, an accessible location and a clear acceptance purpose:

• Investigation brief and findings: the product owner can explain the problem, scope, evidence and limits.
• Current and proposed views: the technical owner can explain relevant boundaries and the differences between observed and intended behaviour.
• Decision log: authorised reviewers can distinguish approved choices from proposals and explain the alternatives rejected.
• Dependency and risk records: owners know the unresolved questions, next actions and commitments they may block.
• Backlog, estimates and staged plan: the delivery team can identify the first work, its acceptance criteria and the conditions behind the forecast.
• Experiment records and supporting material: an authorised engineer can inspect the evidence and understands what was not tested.

Use editable source material and stable references where appropriate, with agreed access and confidentiality controls. A PDF can summarise the result, but it should not be the only home of work the team must update. Record corrections, disagreements and accepted limitations before closing the investigation.

End with an explicit disposition: proceed within the agreed conditions, investigate named questions, reduce scope, defer or stop. Accepting the discovery outputs does not approve production release or every later development cost. If the next stage is platform development, agree its scope and acceptance separately. Use the product launch guide to connect the resulting plan to launch decisions.

Some questions require a different depth of review. The related material on MVP and production capability addresses operating completeness; multi-brand architecture addresses shared and brand-specific boundaries. If the decision concerns acquiring or investing in an existing platform, use technical due diligence rather than assume a product discovery provides the same transaction assessment.

• Can we explain the choice? Ask a receiving owner to state the recommendation, the decisive evidence, the alternatives and the remaining limits.
• Can we start the first work? Check its scope, owner, required access, dependencies and observable acceptance criteria.
• Can we challenge the forecast? Identify the assumptions, effort versus elapsed time, unconfirmed costs and the next evidence gate.
• Can we maintain the result? Locate editable records, confirm access, assign owners and agree when decisions or risks must be reviewed.