How long do discovery and alpha last?

GDS gives typical lengths for both: 4 to 8 weeks for discovery and 6 to 8 weeks for alpha. It gives no set length for beta or live.

What is the difference between private beta and public beta?

In private beta the team invites a limited number of people to use the service. In public beta anyone who needs the service can use it. A beta assessment comes between the two.

Can a team stop after discovery?

Yes. GDS writes that stopping at the end of discovery is not a failure when the research shows that stopping is the best thing to do.

Is there a service assessment at the end of discovery?

GDS's guidance describes assessments at alpha, before public beta and before live. Your department may review a discovery in its own way, so ask your assurance team what it expects.

When does a service move from beta to live?

After its live assessment, which GDS places at the end of public beta. With a green or amber result the service can go live.

Discovery, alpha, beta and live: what each phase is for

A government service team works through four phases. In discovery the team learns about the problem. In alpha it tests ideas with prototypes. In beta it builds the service and opens it to users, first to a few and then to everyone. In live it runs the service and keeps improving it. GDS sets out each phase in the Service Manual. A panel assesses the service against the Service Standard at alpha, before public beta and before live.

Discovery: understand the problem

In discovery the team finds out who the users are, what they are trying to do and what limits the team’s options. GDS writes: “You should not start building your service in discovery.”

GDS sets no length for a discovery and says “around 4 to 8 weeks is typical”. The team it asks for is small: someone with product management skills, a user researcher and a service designer.

Before alpha, the team has to be able to say:

that there is a viable service it could build that would make things easier for users
that the problem is cost effective to pursue
which ideas it wants to test in alpha, and which one comes first
roughly who it will need on the alpha team
how it will measure success

GDS adds that stopping at the end of discovery is not a failure when the research points that way.

Alpha: test the riskiest ideas

In alpha the team builds prototypes and tries different ideas with users. GDS asks teams to find their riskiest assumptions and test those, and to expect to throw the code away at the end. The public must not be able to use an alpha service.

Alphas tend to last 6 to 8 weeks, so GDS advises teams to book the alpha assessment within a fortnight of starting. The department must also appoint a service owner during alpha.

To move on to beta, the team has to be confident that it can build something that meets users’ needs and is cost-effective. It has to know it will have the budget and the people for beta, including a budget for research, and it has to have a plan for accessibility. A team that is not confident can stop, or repeat discovery or alpha.

Beta: build the service and open it in two steps

In beta the team takes the best idea from alpha and builds it for real. Private beta comes first. The team invites a limited number of people to use the service and improves it from what they do. After a beta assessment the team opens the service to anyone who needs it, and that is public beta.

For the beta assessment GDS asks the team to show regular accessibility testing, research sessions with disabled people and the results of an accessibility audit, with the problems fixed. If the new service replaces an old one, the department keeps the old one running until the new one goes live. The team may have to grow in beta. GDS mentions more developers, designers, content designers and performance analysts.

Live: run the service and keep improving it

The live assessment comes at the end of public beta. Before the service goes live, the people who support users have to understand the online part of the service, and the team has to settle who stays on to run it.

GDS writes that live “does not necessarily mean having an agile team on the service 100% of the time”. The team still has to be able to improve the service, basing each change on user research and testing it for accessibility. When users no longer need the service, or so few use it that it is no longer cost effective to run, the department retires it.

How the panel’s result affects your next phase

A cross-government panel gives a green, amber or red result. With green, the service moves to the next phase. With amber it also moves on, while the team fixes the issues the panel found. With red it stays in its current phase until a panel has reassessed it.

Approval to spend

The digital and technology spend controls were replaced on 1st April 2026. Departments now make most of their own digital and technology spending decisions. GDS asks teams to tell their department’s assurance team about new ideas and planned spending as early as they can. A department still has to go to HM Treasury for spending above its limit, or for a proposal that is novel, contentious or repercussive.

Find your phase and list what comes next

Work out which phase your service is in and read GDS’s page for it. Then list what GDS asks you to show before the next phase and mark what you already have.

If the next step is an assessment, read our guide to preparing for a service assessment. Our one-day course, Agile Across the GDS Service Standard, covers what good looks like in each of the four phases. If the phases are new to you, start with Agile Fundamentals for Civil Servants.