You’ve tested your solutions to user needs and built up a clear picture of what it will take to build and operate your service. Now you will build an end-to-end service, test it in public and prepare to go live.

Watch Martyn Inglis, GDS technical architect, describe what happens during the beta phase.

The objective of a beta

The objective of this phase is to build a fully working service which you test with users. You’ll continuously improve on the service until it’s ready to go live, replacing or integrating with any existing services.

This is achieved by providing the user stories in the backlog created in the alpha phase. This is the time to resolve any outstanding technical or process-related challenges, get the service accredited and plan to go live.

You’ll also be resolving technical and process challenges, meeting for the first time many of the technical criteria outlined in the service standard. You should be rapidly releasing updates and improvements into the development environment, and measuring the impact of your changes to the key performance indicators (KPIs) established in your discovery and alpha phases.

You’ll also test the assisted digital support for the digital service. You might test one or more of the options you developed in the alpha phase.

How to publish a beta

There are various ways of running the beta phase. In all instances, it should involve interacting with a full, end-to-end version of the service.

Private beta

This is a beta that is not open to everyone – either regional, or invite only etc. You might want to choose this option because it:

  • gives more control over the audience demographic that gets to use the beta
  • allows you to restrict the volume of transactions that go through the beta
  • lets you start small and get feedback faster before rolling it out to a wider audience

Public beta

A public beta is made open to everyone. It can exist alongside an existing version of the service and you might:

  • use something like AB-testing to funnel some traffic to the beta
  • invite people with a separate call to action to use the beta

Duration of the beta phase

The exact duration of your beta will depend on the scope of your project, but an appropriately sized team shouldn’t take more than a few months to create a beta.

Following the release of your beta you’ll spend some time iterating on the service until it is ready to go live.

Team requirements

You’ll now know what size team you need to create the service, scoping it in response to the findings of your alpha prototype(s). It will be run by a single, suitably skilled service manager, and will include designers, developers, web operations specialists and performance analysts as appropriate.


At the end of the beta phase, you’ll have:

  • delivered a (private or public) end-to-end service
  • a collection of prioritised work to be done (your backlog)
  • a user testing plan
  • accurate metrics and measurements to monitor your KPIs
  • tested the assisted digital support for your service
  • a working system that can be used, for real, by end users