An iGaming Discovery and Architecture Sprint That Leads to a Decision

A roadmap can name a new brand, another payment provider or a platform rebuild without answering the question that makes the investment defensible. Can the current wallet support the new flow? Will the supplier expose the evidence needed for reconciliation? Does the proposed architecture fit the team that will operate it? Booking more development before answering those questions can turn uncertainty into expensive commitments.

A discovery and architecture sprint is a bounded investigation for product, technical and operational leaders. SPINDO.TECH can help frame the decision, examine real workflows, compare options and define the evidence required for the next stage. The useful result is an agreed recommendation with its limits, not an impressive diagram or an automatically approved full build.

Start with the commitment you are not yet ready to make

Write the decision in a sentence: “Should we add the new provider through the existing payment module, create a separate service or change the platform first?” Then name the business outcome, the deadline for that decision and the commitment it controls. “Design our future architecture” is too broad unless you identify which choices need to be made now.

Separate what is known from what is assumed. A signed contract is different from a planned partnership; an observed transaction trace is different from a supplier’s description. Identify the unknowns that could invalidate the plan and the evidence that would change your recommendation. Agree who can accept the result, what is outside the investigation and what happens if access or supplier answers do not arrive.

The GOV.UK discovery guidance, written for public services, separates understanding the problem from building the service and recognises stopping as a valid outcome. That distinction is useful here too. Our combined discovery and architecture scope may include agreed, isolated technical experiments; they are investigative outputs, not a production release. Set the duration from the question, available evidence and participants rather than promise that every product can be understood in the same number of days.

Bring evidence and the people who can resolve it

Prepare a small evidence pack: the current player and staff journey, system and supplier boundaries, relevant API documentation, redacted transaction traces, known incidents, operating constraints and the existing delivery plan. For a live platform, include the data you can actually export and the change windows you can use. Share only authorised material, with personal data and secrets removed where they are unnecessary.

Involve someone who owns the product outcome, an engineer who understands the current system and the people responsible for finance, support and supplier relationships where the decision affects them. A developer can explain a timeout; finance may reveal the reconciliation work it creates; support may show how long a player waits without an answer. Include security expertise for sensitive boundaries and qualified advisers for the operator’s legal and regulatory requirements.

Record every dependency with an owner and an evidence request. If a provider’s production permissions, status lookup or export format remain unknown, do not replace the missing answer with an optimistic design. Label the constraint and decide whether to obtain confirmation, investigate another option or pause. A broad platform capability map can help locate responsibilities; the sprint should focus only on those that affect its decision.

Test the assumption that could change the plan

Consider a hypothetical second-payment-provider decision. The risky assumption is that the current wallet can recognise the same deposit across a delayed response, a status lookup and repeated notifications. Test that seam before designing an entire service estate.

In an isolated experiment, suppose an eligible account starts with EUR 0.00, one permitted EUR 50.00 deposit is confirmed and there are no holds or other movements. Withhold the initial response, then deliver the confirmation twice. The intended result is one recorded credit and EUR 50.00, not EUR 100.00. Retain the internal operation identifier, provider reference and relevant merchant/account scope, and examine what happens when the same reference arrives with conflicting player or amount data. That conflict requires investigation rather than a second credit. Include a crash between accepting confirmation and recording the credit: operation identity, duplicate protection and the wallet effect must remain consistent through recovery, so an accepted deposit is neither lost nor applied again.

The experiment should trace the operation from submission through an initially unknown outcome to authoritative confirmation and wallet evidence. Review how notifications are authenticated, which component can credit the wallet, how a retry reuses the operation and what support can inspect. Use a controlled test double, or an authorised sandbox where available; document what each represents. If the provider has no supported status inquiry, test the agreed alternative completion path instead of inventing an endpoint.

Keep the experiment narrowly scoped and disposable unless a separate production implementation is approved. Its report should state the input, observed outcome, environment, missing cases and decision affected. A passing simulation does not prove provider certification, production permissions, real load capacity or safe operation for restricted players. If the experiment exposes a missing wallet interface, that can justify changing the delivery sequence before funding the integration.

Compare architecture options and record the consequences

Compare options against the same question. Extending an existing module may preserve one financial authority and require fewer new operational responsibilities. A separate service may provide an independent release boundary, but adds message handling, deployment, incident ownership and consistency work. A vendor capability may reduce implementation work while adding contractual, access and exit constraints. A larger rebuild needs its own justification; it should not win merely because it looks cleaner.

For each viable option, show the state owner, integration contracts, change to the current workflow, failure and recovery path, migration needs, staff skills and ongoing cost. Include provider onboarding, parallel operation, support and security work in the estimate. Give ranges tied to assumptions and confidence; separate engineering effort from elapsed time waiting for approvals or access. List the missing evidence that prevents an estimate rather than invent precision.

Capture consequential choices in architecture decision records. AWS guidance on ADRs describes recording context, the decision and its consequences, with accepted decisions superseded by new records when they change, preserving the earlier decision in the history. Add the options considered, evidence, owner, status and trigger for review. An option still waiting for a supplier answer should remain proposed, not appear accepted in the handover.

The broader iGaming platform architecture guide explores financial authority and service boundaries. Here, diagrams and records should be just detailed enough for the next team to implement the chosen slice and understand why another option was rejected.

Turn quality requirements into observable scenarios

Replace “fast, secure and scalable” with scenarios the team can investigate or implement. Describe the eligible user, operation, environment, load or failure, expected response and evidence. For response time, identify the journey and measurement point, percentile and traffic shape, then agree the target. For recovery, specify which accepted operations must survive an interruption, who may resume processing and how correctness will be reconciled. Numbers without that context are not requirements.

Model sensitive data flows and trust boundaries, including staff access, provider messages and cross-brand data. OWASP’s threat modelling guidance connects the system model to threats, responses and reviewable mitigations. Apply that approach to the selected flow: ask whether a forged notification could credit an account, whether a staff role could bypass an approval and whether investigation logs expose personal data. Turn agreed responses into owned work with testable acceptance criteria.

Distinguish evidence levels in the report. A document review establishes what the contract says; a sandbox test establishes behaviour in that environment; a design review identifies assumptions and gaps. None automatically demonstrates production readiness. Discovery can define controls and validation work, but cannot issue an operating licence or replace a required security assessment. Unresolved high-impact assumptions need an owner and a next test, not a reassuring green label.

End with a decision and a usable next stage

Close the sprint by reviewing the original decision with the people authorised to make it. Choose whether to proceed with the selected option, run a narrower investigation, renegotiate a dependency or stop. Explain the evidence and uncertainty behind that recommendation. If a critical assumption is unresolved, say which commitment must wait and who will obtain the missing answer.

Turn an approved direction into a first delivery stage with a complete workflow, dependencies, acceptance evidence and a responsible owner. For the payment example, that stage may cover submission, unknown status, confirmation, one wallet effect and support investigation before adding more providers. Decide what must be proved before live exposure, including applicable permissions and operational support. The new-product launch guide helps define those later release gates.

Hand over editable records, references to authorised evidence, experiment instructions and results, estimates with assumptions, prioritised work and the unresolved decision log. Confirm where the client team can access them and which supplier materials have sharing restrictions. The receiving team should be able to explain the recommended boundary and continue without reconstructing private workshop conversations. Working production software is a separate deliverable that must be explicitly scoped.

To discuss a focused engagement, contact SPINDO.TECH with the blocked decision and available evidence. Agree the participants, investigation scope, outputs and acceptance before committing. The sprint is worthwhile when it changes a decision or makes the next commitment defensible, even if the answer is to build less.

• Decision brief: the outcome, commitment, scope, constraints, decision owner and evidence needed to proceed.
• Investigation record: assumptions, authorised inputs, experiments, observed results and limits of what was tested.
• Architecture choice: comparable options, responsibilities, accepted or proposed ADRs, consequences and review triggers.
• Next-stage brief: a complete initial workflow, dependencies, cost assumptions, acceptance evidence, handover access and unresolved decisions.