Beta

Purpose

Beta is where the preferred alpha approach is built and tested with real users. The goal is to develop a usable, secure and supportable service or product and prepare it for live operation.

When to Use This Phase

Use beta when alpha evidence supports a preferred solution and the customer is ready to build, test and release usable increments with real users.

Primary Decision

At the end of this phase, we should be able to answer:

Is the service good enough, safe enough and operationally ready enough to move into live use?

Core Questions

• What is the minimum viable service?

• Which users will access private beta?

• When can public or wider beta begin?

• What must be tested before live?

• What support model is needed?

• What metrics will show performance?

• What security and data evidence is required?

• What defects or risks block live release?

Key Activities

• production-grade build

• private beta release

• public or wider beta release where appropriate

• user research with real users

• accessibility testing

• integration testing

• security testing

• performance testing

• service support design

• operational readiness planning

• release planning

• defect management

• documentation

Expected Outputs

• working service or product

• release notes

• tested user journeys

• support model

• operational documentation

• security evidence

• performance evidence

• accessibility evidence

• service metrics

• live readiness assessment

• updated roadmap

Entry Criteria

• alpha recommendation approved

• beta Statement of Work agreed

• backlog prioritised

• team mobilised

• environments available or planned

• security approach agreed

• acceptance model agreed

Exit Criteria

• service works for intended users

• critical user journeys are tested

• security and assurance requirements are met or risk-accepted

• support model is ready

• monitoring is in place

• performance is acceptable

• live release decision is recorded

Evidence to Capture

• completed backlog items

• test evidence

• user research findings

• defect log

• accessibility report

• security review

• deployment records

• monitoring evidence

• support readiness checklist

• live readiness report

• acceptance certificates

Commercial and Statement of Work Considerations

• tie milestones to evidence and accepted deliverables

• use change control for material scope changes

• track customer dependencies that affect delivery

• maintain payment evidence

• ensure supplier deliverables support acceptance

IP and Accelerator Considerations

• separate reusable components from customer-specific outputs where possible

• confirm ownership and licence of any foreground IP

• record open-source components

• avoid embedding restricted customer material into reusable assets

• update accelerator library only after IP review

Security, Data and Assurance Considerations

• apply secure development practices

• manage secrets properly

• run vulnerability checks

• confirm access controls

• test data handling

• prepare security evidence

• confirm incident and support routes before live

Common Risks

• beta treated as a full uncontrolled build

• private beta feedback ignored

• operational support designed too late

• security evidence delayed

• performance issues discovered at live gate

• scope expands without change control

• supplier tasks not integrated into release plan

Practical Checklist

• Confirm beta scope and acceptance criteria

• Set up environments and repositories

• Build and test increments

• Run private beta with selected users

• Capture and prioritise feedback

• Run security, accessibility and performance checks

• Prepare support model

• Prepare live readiness evidence

• Run beta exit review

• Record live decision