Complete our quick 5-question survey to help us improve our content.

  1. Service manual
  2. Agile delivery
  3. How the beta phase works

The objective of the beta phase is to build a working version of the service based on your alpha prototypes.

The version you build must be able to handle real transactions and work at scale.

You also need to keep improving your service and replace existing services or integrate with them.

What to do in beta

You need to do the following in the beta phase:

The team you need in beta

Find out the team you need in beta.

Launching your service in beta

You must launch your service in private beta before you launch it in public beta.

Private beta

A private beta is a beta that isn’t open to everyone. You must restrict access. Don’t launch your service publicly in private beta - make it invite-only or launch it in a limited region.

A private beta allows you to:

  • have more control over the type of user that gets to use the beta
  • restrict the volume of transactions that go through the beta
  • start small and get quick feedback before rolling your service out to a wider audience

Public beta

A public beta is a version of your service that’s available for any member of the public to use.

You must pass your beta service assessment before you launch your service into public beta.

How long the beta phase takes

The length of time your beta takes depends on the scope of your project, but if you’ve got the right team in place it shouldn’t take more than a few months.

When you’re ready to move on to live

After the release of your beta, you need to keep iterating and improving your service.

Your service is ready to move on to the live stage when you’re sure:

  • it meets and can continue to meet the Service Standard
  • you can support it and you’ll be able to keep iterating and improving it until it’s retired

What you need by the end of beta

At the end of the beta phase, you should have:

  • launched a private beta followed by a public end-to-end beta prototype
  • made a prioritised list of the work you need to do (a backlog)
  • made an ongoing plan for user research
  • found a way to measure your service’s success using new data you’ve got during the beta phase
  • evidence that your service meets government accessibility requirements
  • tested the way you’ve designed assisted digital support for your service
  • built a working service that can be used in full by users

You may also find these guides useful:

Published by:
Agile delivery community
Last update:

Added guidance on how to meet government accessibility requirements in beta.

  1. Guidance first published