Open Beta

Stage

A stage where anyone can sign up and use the product, while a visible label tells them it isn't finished yet.

Why it exists

Showing unfinished work to the public used to be treated as a straight loss of reputation. Teams went as far as a closed beta, where only invited people get in, and kept the doors shut until everything was done.

That route hides things. Pagedeck ran document comments with 40 invited users for three weeks and collected two bug reports. On the first day of public access, with several thousand people arriving at once, notifications fell hours behind and comments on long documents attached themselves to the wrong lines. Neither problem can appear at a scale of 40. The way people used the feature was off too: teams were not leaving opinions in comments, they were handing out work.

Waiting until all of that is fixed only pushes the date you learn it further out. Opening the doors all the way, taking the real load and the real usage, and posting the fact that the work is still in progress so expectations drop in advance — that combination is what the stage settled into.

What this stage looks like

The doors are open to everyone and a label sits on the screen saying the work is unfinished. There is no invite code and no waitlist; you sign up and you are in, next to a word like beta near the product or feature name. Measured by who can get in, it matches general availability (GA), the state in which every customer is served formally. The only difference is the size of the promise attached to the screen.

In practice the stage shows up in four ways.

  1. The user count jumps by an order of magnitude. Tens of invited accounts become thousands, and response times and error rates get seen at real scale for the first time. That check is the main reason the stage exists at all.
  2. Support and remedies run below the finished level. No commitment to answer within 24 hours during an outage, no guarantee that corrupted data will be restored. In exchange, that limit is written down where people can read it before they start.
  3. Screens and behavior keep moving. Watching how arrivals actually use the thing, the team changes button placement and defaults week to week, and publishes what changed in a release note.
  4. A way back stays in place. Shipping behind a feature flag, a switch that turns a feature on and off while the code stays deployed, lets the team close the feature again without undoing the deployment. Anything larger gets a rollback to the previous version.

What the word beta actually does is lower expectations ahead of time. Meeting the same error, someone on a screen labeled beta files a report and moves on, while someone on a screen labeled finished asks for a refund. The label is less a polite disclaimer than a device for sharing risk with the people who chose to come in early.

What moves you to the next one

The test for moving to general availability is not whether the features are complete. It is whether the team can carry the promises that come with removing the label. Pagedeck looks at four things.

  1. Whether the numbers hold. Error rate and response time have to sit under target for two weeks or more. A single good day does not count, because the stage exists to catch what only shows up under sustained traffic.
  2. Whether the severe list is empty. Anything that loses data or shows one team's document to another blocks the move, even if it is the only item left. Annoyances stay on the list and travel with the release, to be fixed after the label comes off.
  3. Whether people stay. Enough newly arrived teams are still using the feature two weeks later, and a satisfaction measure such as Net Promoter Score (NPS), calculated from how willing users are to recommend the product, has not dropped.
  4. Whether the company can receive them. A support channel, pricing and refund rules, and a named person who responds within a set number of minutes during an outage. Where this part is missing, the move waits no matter how healthy the software looks.

How long a product sits here follows no rule. Four weeks is short; a payment or permissions feature, where mistakes are expensive to undo, can stay for six months. What sets the length is the cost of being wrong, not how polished the work feels.

The direction is not always forward either. When something serious surfaces, the doors narrow back to invited users only, or the feature goes off and the work restarts. Saying plainly that it was pulled back usually keeps the remaining users waiting rather than leaving.

How it sounds at work

"We're going to open beta next week. Everyone on the waitlist gets in that day."

The invite limit is coming off, so anyone who wants an account will be able to create one.

"We can't sign a service level agreement while it's still in open beta. That comes after GA."

Service quality isn't being promised contractually during this stage.

"Let's look at two weeks of open beta numbers before we decide on GA."

The label comes off only after the metrics clear their thresholds.

At Pagedeck, Mia picks the open date and Theo checks in advance how far the user count can multiply before something gives. For the first two days after the doors open, the team watches errors and response times closely and closes the feature on the spot if anything looks wrong. Ravi deliberately keeps advertising small during this window, because bringing in a crowd while screens are still changing sets a first impression that sticks. Sofia demonstrates the feature to enterprise customers but does not sell it yet.

What people get wrong

The most common misreading is that the label transfers responsibility away from the team. Announcing that something is unfinished makes that easy to assume. But the label lowers expectations, and nothing more; it exempts nobody from losing a customer's data or exposing another team's documents. Once a problem crosses that line, the affected users do not come back, and "it said beta" reads as evidence the thing was opened without preparation rather than as a defense.

The other misreading is that open beta means free. Plenty of products charge nothing during a beta, so the two ideas travel together, but pricing is a separate decision from stage. Some products charge list price throughout a beta, and others keep a free plan long after the label is gone. Bundling the two leaves teams thinking they have to invent pricing at the moment they move to GA.

Easily confused with

TermWho gets inHow it differs
Closed betaInvited users onlyChoosing the group controls both the kind of feedback and the blast radius of a failure. Open beta gives up that control in exchange for seeing real scale

Where to go next

  • Release

    see which flow this stage belongs to and where it sits in it

  • Alpha

    the stage before it, with the narrowest door

Last updated 2026-09-16