Delivery framework

The same five steps, every engagement

Our approach sits between capability and service. It is deliberately boring: the shape does not change per client, so the conversation stays on the outcome rather than on the method. Below is what goes in, what happens, and what you get out of every step.

User researchDiscoveryAlpha/ private alphaBeta/ private betaLive · CI/CD
Step
Key inputs
Activities
Outcomes
01

User research

Continuous. Usually starts before you engage us.

  • Business goal and the outcome being bought
  • Existing analytics, support tickets, call logs
  • Access to real users and frontline staff
  • Regulatory and accessibility obligations
  • Contextual interviews and observation
  • Task analysis and journey mapping
  • Accessibility and assisted-digital needs
  • Desk research on market and competitors
  • Validated user needs, evidenced
  • Personas and journeys agreed by both sides
  • Problem statement worth funding
  • Research backlog that keeps running
02

Discovery

Pin down the requirement. Make it visible.

  • Research findings and problem statement
  • Current architecture, data and integrations
  • Constraints: budget, dates, policy, skills
  • Named decision-makers
  • Requirement workshops and prioritisation
  • Concepts and clickable prototypes
  • Technical and data feasibility spikes
  • Re-test every concept with users
  • Joint understanding, visualised
  • Prioritised backlog and target architecture
  • Delivery plan with an explicit first slice
  • Go / no-go with costs on the table
03

Alpha

Usable, not yet complete. QA'd as a private alpha before it goes near live.

  • Prioritised backlog and architecture
  • Environments, pipeline and test data
  • Security and data protection requirements
  • Test cohort of real users
  • Iterative build of the core journey
  • Automated test, SAST/DAST and code review
  • Private alpha: usability and QA against real tasks
  • Research revisited against each increment
  • Working software doing the main job
  • Defects and findings triaged, not parked
  • Evidence the approach holds at scale
  • Release decision backed by test results
04

Beta

Feature complete. Private beta widens the audience under control.

  • Alpha findings and outstanding backlog
  • Performance and resilience targets
  • Support model and service owners
  • Migration and cutover plan
  • Complete the build, including the hard edges
  • Full QA: functional, accessibility, load, security
  • Private beta with a widened cohort
  • Runbooks, training and handover sessions
  • Final release, evidenced against acceptance
  • Agreed development backlog for what is next
  • Operational readiness signed off
  • Your team able to run it
05

Live · CI/CD

A state, not a finish line. The loop closes back into research.

  • Release and rollback procedures
  • Observability and alerting thresholds
  • Agreed outcome measures
  • Funded improvement capacity
  • Continuous delivery through the pipeline
  • Measure behaviour against the outcome
  • Ongoing research and experimentation
  • Cost, security and dependency review
  • Small, frequent, low-drama releases
  • Outcome reported in numbers you chose
  • Capability transferred, dependency reduced
  • Next increment already evidenced

Gates, not ceremonies

Private alpha and private beta are QA gates with entry and exit criteria. Nothing passes on optimism.

Research never stops

On a large programme it is a funded workstream for the life of the build, not a phase that closes.

New scope goes to the backlog

Requirements discovered late are welcome. They land on an agreed backlog rather than inside the current release.

Fits your governance

The framework maps cleanly onto Agile, SAFe and stage-gated portfolio reporting where that is what you have to satisfy.