Being in the app store did not mean everybody could use the beta.
The app was moving toward an app-store release. Being available in the store did not mean every person who downloaded it should immediately enter the product. We still wanted a controlled beta while the main flows were being tested.
The discussion happened during backlog refinement and was supported by a short product requirements document. The question was what a new person would see before access was granted.
An access gate needed several states. Somebody might already have an invitation. Somebody else might want to join a waitlist. A code could be valid, invalid, or already used. The app needed to respond clearly in each case without exposing information about another account.
The gate also had to fit the public website. If the site described one way to request access and the app asked for something different, people would arrive without knowing what to do.
The private record includes implementation decisions and internal review material. It also includes individual testers and codes. None of those details are reproduced here.
The public-safe event is that beta access became a product feature of its own. It was not enough to keep a private list outside the application. The released build needed a visible and understandable boundary around who could continue.
We treated the gate as temporary but real. It needed design, copy, error handling, and a way for the team to change access without shipping a new version of the app.
The same rules needed to work after an application update. Access could not depend on a tester keeping one particular build installed or repeating an approval step every time the software changed.
That work went into the release plan. The mobile build was getting closer to distribution, and the first screen had to distinguish availability in the store from permission to use the beta.