Right Way/Wrong Way: Closed Betas

That's right, everyone—it's time for a thrilling episode of “Right Way/Wrong Way,” in which we see two possible solutions to a problem. One of 'em's good, one of 'em's bad, but we can all learn something from both of them!

This time: closed betas.

The closed beta scenario is very common; you're working on a site that will change the game completely, and you want feedback from various people while you're fine-tuning things. You deploy the site, but you want to keep the whole thing (except a teaser homepage, usually) behind some sort of login.

Solution 1:

Require people to log in to access any part of the site, and make the registration form available only via invitation. This is as simple as slapping a before_filter :require_login on your ApplicationController (with the appropriate skip_before_filter for your registration action)—but it'll bite you when you go to take the site out of beta. You'll be forced to go through controller-by-controller and add the login requirement individually. What's more, your functional test suite won't be as useful anymore, since you won't be testing any cases with an unauthenticated user (all of which would've failed during the beta). This, then, is the Wrong Way.

Solution 2:

Instead of requiring login at the application controller level, go ahead and build your site as it will eventually be—some actions requiring authentication, some not. Then, for the closed beta, slap on an after-market extra authentication piece, either using Rails's built-in support for HTTP authentication or some sort of cookie-based system. One version of this I've used in the past has invited users visit a special URL that sets an invited cookie with a two-month expiration (or however long the beta will last). Anyone who lacks the cookie sees only the teaser homepage, but once you've got it the whole site is open to you. Transitioning out of closed beta is as easy as removing the bolted-on extra authentication piece. Welcome to the Right Way. Of course, there are other possibilities; the point of this isn't to describe the only workable solution, but to get you thinking about the issue. While we might not be doing Big Design Upfront, we still need to keep the bigger picture in mind at times (which the Wrong Way here fails to do)