Beta

Beta is where the real service takes shape. You build working software, put it in front of real users — often starting with a private beta — and improve it based on how people actually behave, not how you hoped they would.

At a glance

What good looks like

• Real users — not just the project team — complete realistic end-to-end tasks.
• Performance, security, and accessibility are treated as features, not launch blockers discovered at the end.
• Support teams are involved before launch and have clear escalation paths.
• Metrics are live and the team uses them to prioritise improvements.

Common mistakes

• Launching publicly before private beta surfaces the obvious failures.
• Deferring operational readiness — hosting, monitoring, on-call — until after launch.
• Treating Beta as a feature freeze rather than a period of intensive learning.
• Publishing without performance data or a plan to measure success.

Service Standard points in focus

These points often receive particular attention during Beta. See the full Service Standard guide.

• Point 3: Provide a joined-up experience across channels
• Point 5: Make sure everyone can use the service
• Point 8: Iterate and improve frequently
• Point 9: Create a secure service that protects users' privacy
• Point 10: Define success and publish performance data
• Point 13: Use open standards and common components
• Point 14: Operate a reliable service

Double Diamond mapping

Beta is primarily Deliver from the second diamond — converging on a solution that works in production. Iteration continues, so pockets of Develop thinking appear when new features are explored, but the dominant mode is refining and proving what ships. Read the full mapping →

Related phases

• Discovery
• Alpha