Alpha is the development phase that comes after discovery.

In the alpha phase you need to:

  • build prototypes of your service
  • test your prototypes with users
  • demonstrate that the service you want to build is technically possible

You should use your experience building prototypes in the alpha to:

  • find the problems with the design of your service and decide how you’ll solve them
  • make some estimates about how much your service will cost
  • identify the biggest risks for the beta stage, as early as possible

By the end of alpha you should know:

  • whether to move your service into the beta phase
  • what you need to build in beta if you are moving into beta

Stages of a successful alpha phase

Each alpha will be different because the risks and goals for each service are different.

Most alphas are 4 to 8 weeks long and follow these 3 stages:

  1. Inception: getting the team together to set out goals
  2. Iterations: build prototypes, test them, learn, change and test again
  3. Conclusion: move on to the beta phase or end the project

Identify the biggest risks

The reason for running an alpha is to identify all the risks to your project as early as possible. We should try to identify the biggest risks and get a better understanding of them.

Types of risk

In most of our projects, the risks fall into one of the following 4 categories:

  • design
  • business process
  • technical
  • financial

User testing

At this stage we will do private testing with our customers to seek their input and feedback.

We will then use this to iterate our product.

At this stage, our test pages should be given the URL of –


Deciding the alpha phase is finished

At the end of the alpha phase, we should have:

  • user stories – they should relate to the overall user journey rather than being tied to individual features
  • a plan for our beta phase and a (less detailed) plan for our live phase
  • set some metrics to measure the service’s success
  • a basic working system with limited functionality which we can demonstrate to users
  • an understanding of legacy systems we will need to replace or integrate with
  • a decision on whether or not to progress to beta phase
  • an understanding of how to design an accessible service
  • ideas for how we will design the assisted digital support model for our service

Moving on to beta

We should feel confident that we aren’t proposing a project that won’t work at beta.

We need to make sure our timelines, our scope and our vision are correct according to the money and people we have got for the next phase.

Once we are confident that we want to move to beta, the Product Owner will develop an update project plan for the beta phase.


Deciding not to move on to beta

You may also use the alpha stage to decide to end your project rather than continuing into beta.

For example, you may find that:

  • the user needs for the service are already being met by another service
  • it costs too much to build the service based on the number of people who’ll use it
  • there’s a better non-digital solution
  • adapting or developing another service is a better solution

It’s still a successful alpha if you decide not to move on to beta because it means you won’t waste time and money.