Feature flags: Best practices for SaaS products

Patrick Wiseman
CEO and Founder

Feature flags are a powerful tool to help delivery teams unlock the benefits of Continuous Delivery by increasing efficiency, improving business planning for upcoming releases, and enabling fast feedback collection from a small, trusted subset of users.

Feature flags deliver these benefits by making it easy to ship partial features to production through the use of living branches in your codebase that allow you to hide functionality so that you can release it at a later time or release it conditionally.

But as with any tool, feature flags are only as powerful as you make them. Feature flags supercharge a Continuous Delivery practice by allow teams ship safely all the way to production. Beyond that starting point, there are several best practices you can embrace to get the most value out of feature flags.

5 best practices for using feature flags in SaaS development

Based on that understanding, what does your team need to know as you start using feature flags in SaaS development? Start with these five best practices:

  1. Align on names and descriptions

    Make sure your entire team agrees on a name and general description for each feature flag. This alignment will help ensure that everyone has a clear understanding of what functionality each feature flag encompasses and, therefore, what turning it on or off will do. The more stakeholders you have, the more important this clarity becomes. It will also avoid the temptation to reuse a feature flag, for example by using the same one for two features that may not get released at the same time – a practice that can create several challenges.

    Getting this alignment upfront also encourages a discussion on whether or not something really needs to sit behind a feature flag, which is a valuable conversation to have. That said, feature flags are relatively inexpensive to create, so it’s better to err on the side of using one versus shipping a handful of changes to production and then trying to put them behind a feature flag after the fact.

  2. Maintain a living directory of which feature flags exist

    Everyone from QA to designers to product owners needs to make certain accommodations based on feature flags, so it’s important to keep a living directory of them that makes it easy for these users to identify which ones are still in use. They should be documented somewhere that everyone on the team can see – company wiki, superadmin page, etc.

    For example, QA teams should keep a set of test cases related to each feature flag so that they can easily test each permutation that could occur in production. This adds up over time, so it’s important for QA teams to be able to quickly identify which feature flags are live at any given point. Because of this extra effort, QA often leads the charge for removing feature flags that are no longer needed to reduce the number of test cases.

    Meanwhile, designers should refer to the directory of feature flags to identify all the possible combinations of use cases for which they need to account in their designs based on what different users might see.

    Finally, the directory helps product owners better control feature flags and coordinate with cross-functional stakeholders from support, marketing, sales and training to create a full release plan and ensure everyone is knowledgeable about the latest updates.

  3. Set feature flags at the team level

    It’s tempting to implement feature flags at the user level, so that only particular users see certain functionality, but experience reveals time and again that feature flags are most effective at the team level.

    The main reason to set feature flags at the team level vs. the user level is that individuals are often hesitant to reach out to support, no matter how quickly and meaningfully your support team responds. Instead, they’re more likely and happier to ask a colleague. But when their colleague has a different user experience than they do, this can create confusion.

    As a result, setting feature flags at the team level not only avoids confusion (we’ve actually seen tickets come through asking why one user’s experience looks different than the other’s!), but it also alleviates pressure on your support team by enabling your users to better help one another.

  4. Log feature flag usage and track adoption

    Feature flags are intended to be temporary within your product, and you don’t want to keep them around for longer than you have to due to the extra work they create for team members like designers and QA analysts (who must account for every possible permutation). However, it’s far too easy to implement a feature flag and then forget about it, letting it live (and creating extra work) for much longer than it needs to.

    The best way to detect dead flags and identify which long-lived ones you can remove without incident is to use a logging tool that tracks adoption. Specifically, it should track the percentage of users for which the feature has been turned on, that way you can quickly determine when the feature has been turned on for everyone, at which point you can remove the feature flag.

    This type of functionality is available in most business intelligence tools, which will even allow you to create a dashboard and then automatically email weekly reports to keep the feature flag pruning process top of mind.

  5. Don’t use feature flags for permissions

    Using feature flags to set permissions seems like a natural use case, but it’s actually an important thing _not_ to do. Permission models are much more complex and specific than feature flags can handle, making them better suited for a different pattern, like policy objects (which pass a resource to a user in context to determine which actions each user can or can not take).

    Ultimately, no matter how enticing it might be to use the same feature flag infrastructure for permissions, doing so never works out and should be avoided in favor of architectures specifically designed for the complexity of the use case.

Ready to get started?

Feature flags are integral to unlocking the benefits of Continuous Delivery, but they require a thoughtful approach. Following the best practices outlined here can help ensure your team uses feature flags correctly to maximize their value and ensure the success of your Continuous Delivery program.

Interested in learning more about how you can get started with feature flags and maximize their value for your organization? Contact Spaceship today to learn how we can help.

Want to be first in line to get early access to Spaceship?

Be the first to know when we launch! Sign up for our waiting list below: