Closed Beta

Deciding when to open a feature always caught teams between two bad options. Keep it shut until it's finished and you learn where first-time users stall on launch day. Open it unfinished and every customer sees a screen that isn't ready. Alpha — the stage where only people inside the company use it — is safe enough, but the opinions it produces belong to the people who built the thing.

Here is how that played out. Pagedeck's engineers spent two months on document permissions and opened it to every customer at once, and support requests arrived all day. Permission labels that were obvious to the people who wrote them meant nothing to anyone seeing them for the first time. Sofia sent apologies to twenty customer accounts, and fixing the screens took another three weeks.

A closed beta adds one box between those two options. It opens to people outside the company, but the company decides who comes in. Eyes that didn't build the thing get on it, and if something goes wrong the apology list is five accounts instead of twenty.

Choosing who gets in shapes everything else about the stage. The door is usually locked with invite codes or a list of accounts registered in advance. A consumer product might let in a few hundred people; a business product typically runs five to twenty accounts. One or two isn't enough, because then a single company's circumstances read like a problem with the product. Forty is too many, because nobody gets through a week's feedback and the point of selecting participants disappears.

Because you can choose, you can build the group around what you want to learn. Verifying permissions means including a customer with a large team. Watching where newcomers get stuck means not filling the list with long-tenured accounts who already know the product. Do that selection carelessly and the beta finishes cleanly while the same support requests arrive at launch.

This is also a stage that produces sentences rather than statistics. A conversion rate across thirty users isn't a number you can act on, but you can ask one of those users where they stopped. So a separate channel gets opened: a chat room only participants can join, or a feedback button inside the screen, with someone collecting what came in once a week and ordering it.

The level of commitment differs from a full launch too. Participants are told in advance that an outage carries no compensation, and sometimes that data may be wiped. It's usually free, because charging turns a trial into a service.

Two weeks to two months is the usual length. Too short and you collect only first impressions, never the friction that shows up on repeat use. Too long and participants burn out and stop answering. Pagedeck runs three weeks by default, with one conversation in the first week and one in the last.

The test isn't whether the feature is finished. It's whether a wider door is something the team can absorb. Four checks usually decide it.

1. No severe defects remain. Anything that loses data or shows one customer another customer's documents blocks the move on its own.
2. People can use it unassisted. Beta participants had a human walking them through it; in the next box, nobody does. Watch whether a newcomer completes a first task without help text.
3. Support volume is predictable. Thirty users generating two requests a day tells you roughly what three thousand users will generate, and that estimate gets checked against Sofia's current headcount.
4. There's a way back. Theo confirms that the feature can be switched off and the previous state restored if something breaks.

There are two directions forward. Throw the door open and it becomes an open beta; take the label off entirely and it's general availability (GA). Teams sometimes add one more box first and open to a slice of paying customers through an early access program (EAP). Backward is a direction too. If the beta shows the premise was wrong, the feature closes and goes back to alpha. Making that call cheaply is the reason the box exists, so retreating is the stage working rather than the stage failing.

"Let's put permissions in a closed beta first and decide in three weeks."

Open it to a narrow group before general release and defer the decision.

"Please get two of the large accounts onto the closed beta list."

The situation worth testing only appears at those accounts, so they belong in the group.

"It's still in beta, so I told them this screen may change."

Notice was given in advance that what's on screen isn't final.

When Pagedeck rebuilt those permissions, the order changed. Mia picked five customer accounts and sent invitations, and Sofia spent thirty minutes on the phone with each contact beforehand, listening to how they handled permissions today. Once it opened, Theo and Noa sat in the participants-only chat room answering questions directly.

Half the feedback gathered over three weeks landed on the permission labels. Noa renamed them and added a line of explanation on the screen before the door widened, and this time launch day brought three support requests.

The most common mistake is treating a closed beta as a quality assurance stage. Bugs surface here, so the reading is understandable, but bug hunting should be finished before this box. What gets tested here isn't whether the build runs — it's whether people outside the building use it the way they need to. Miss that distinction and the beta ends with a bug list, while the fact that nobody wants the feature arrives after launch.

The other misreading is that the beta label excuses everything. You said it was unfinished, so anything goes. What users actually forgive is thin functionality and rough screens. A document that disappears, or another team's files showing up, is an incident in a beta exactly as it is anywhere else. Once that happens, participants leave instead of writing feedback, and the rest of the beta runs with nobody in it.