Welcome to A/B rollouts.

The idea is that instead of making a sweeping change for every single user, you roll a feature/system/UI update, etc out to a small number of users, to see how effective it is. It gives you time to see how those users react to it, how they interact with it, how it impacts their broader site usage, etc… And then once they have had time to gather some feedback and work out the bugs, they push it out to the rest of the users.

Most big tech companies use A/B rollouts nowadays. YouTube, Meta, Reddit, TikTok, etc all give users access to different updates at different times. Because it allows them to gauge how their users are actually interacting with the updates before they accidentally tank their entire system with a bad update.

For new features, it can also give the company time to properly scale their backend systems to accommodate a new feature. For instance, when Tiktok rolled out images in comments, they likely had to do some work on the backend to ensure their systems could handle the added load of suddenly downloading a bunch of images any time a user opened a comment section. By phasing the rollout in multiple steps, they didn’t have to upgrade all of their systems up front before making the feature available to some/most users.

Using this post as an example, imagine if there was a bug that didn’t allow users to log in after they got this prompt. Or didn’t allow logged in users to access the site, because it kept redirecting them back to this page. Or it allowed users to continue browsing without a login, as long as they were in Dark Mode. Or any number of other potential weird issues that could arise. The A-users are essentially pushed into beta testing the new feature, before the B-users get the update. In this case, you’re simply a B-user who hasn’t been scheduled to get the update yet.