Stability levels in practice
A Stability level tells everyone how stable something is right now. It exists so you can move fast: show work early, get feedback, and move it up as soon as it's ready, without anyone mistaking rough work for something finished. This page covers how to use stability levels with clients.
Stability levels explains what each level means from the client's side, and the Stability checklist what each one generally includes. Marking stability levels covers labels and versioning, and the design system how to show a level in software.
Use stability levels to move fast
- Show work early. A prototype on the second day of a block is worth more than a polished feature on the last, because the client can still change direction. The level is what makes showing rough work safe.
- Invest only what the current level needs. Don't build GA error handling into something the client hasn't seen yet. Get the direction right first, then harden what survives. The client should see and try the work at every level, so nothing goes past Beta on a guess.
- Move up as soon as it's ready. You don't need a checkpoint, a review, or anyone's sign-off to move from Prototype to Alpha. Use your judgment and tell the client.
- Expect any pace. A feature can go from Prototype to GA within one iteration, or stay in Beta for several while real use shakes out the edge cases. Moving between levels walks through a feature that went through every level in one block.
Setting expectations with the client
Clients don't read test coverage or dashboards. They decide what to depend on, and the stability level is how we tell them, in one word, what the work can bear.
-
Say the level whenever you show something, and what it means for them:
Level What to tell the client Prototype "React to this and tell us which direction is right. The data may be fake, and it may change completely." Alpha "Try it with real work and tell us what's wrong. Expect it to change, and keep your fallback." Beta "Use it for real, with a fallback for anything critical. We aim to tell you before anything breaks, but can't always." GA "It's ready for anything. It will keep working the way it does now." -
Check with the client before moves that change what they rely on. Putting a feature in front of their real users, or calling it GA, needs their yes. A quick message is enough: "Invoice export is at Beta. Can we try it with a few of your finance team this week?" Other moves, just tell them.
-
Label it for what it is, not what you hope. If something isn't as stable as its level says, tell the client and fix the label or the work. A level that overstates stability is how a client ends up depending on something that isn't ready.
-
Name the gaps. Say which checklist items for its level aren't done yet, and what's missing for the next one, such as "no alerts yet" or "untested above ten thousand rows," so the client can judge the risk themselves.
-
Say what's worth hardening next. Not everything needs to reach GA. Point out the features the client is starting to depend on, since those are the ones worth getting there.
When the client needs GA soon
If a deadline is close and the client wants something GA, explain what GA promises: it keeps working, it's monitored, and breaking changes wait for a new version. Then offer the options:
- Harden it now, using the checklist to show what's left.
- Narrow what goes GA to the part they actually depend on, and leave the rest at Beta.
- Agree an exception for a specific item, such as "GA without mobile support," and note it in the release notes so no one is surprised later.
Use the checklist to judge readiness
The Stability checklist lists what should be in place at each level, area by area. It's what we aim for, not a gate, and clients read it too, so it's the shared reference for what a level means.
- Check where the work stands before you move it up, and name the gaps that apply.
- Reviewers use the label to calibrate. Don't ask for GA polish on a prototype, and don't wave through prototype shortcuts in GA work.
Frequently asked questions
Do I need approval to move something up a level?
No. Move it when it's ready, and tell the client. Check with them first only when the move changes what they or their users rely on, such as trying it with real users or calling it GA.
Do I have to meet every checklist item before moving up?
No. The checklist is what we aim for, not a gate. Use it to judge whether something is ready, and if an item that matters isn't met, tell the client so they can weigh it.
Can a feature move through several levels in one block?
Yes. Prototype in the morning and Alpha by the afternoon is fine, and so is Prototype to GA within one iteration, if the client has tried it along the way and the work is ready. See Moving between levels for an example.