Feature Flags: Overhyped for Startups
When it comes to managing feature releases at startups, various strategies have been proposed, but one that's caught significant attention in recent years is the use of feature flags. Feature flags are essentially a kind of toggle used by developers to enable or disable specific functionalities in a software product. Despite their popularity, their practical application, particularly in early-stage companies, is not without its complexities and potential drawbacks. As an engineering leader navigating the uncertain waters of a startup environment, understanding these challenges is crucial to optimizing your development and release strategies.
This blog aims to shed light on the utility and potential complications of feature flags, with a special focus on their relevance in early-stage companies and startups.
Understanding Feature Flags
At a basic level, feature flags offer developers the flexibility to modify system behavior without changing code1. This decoupling of system behavior from code deployment can ostensibly reduce risk, but the reality, particularly in early-stage startups, can often be more complex.
The Added Complexity of Feature Flags
Despite their theoretical advantages, feature flags can introduce considerable complexity into the release process2. In an early-stage startup, where teams are small, work across lines, and operate under many unknowns, this complexity can be an unnecessary burden.
One of the major issues is that even with feature flags, live code is still going into production. As Jason Lemkin, the founder of SaaStr, pointed out, the risk of having unproven code in the production environment remains3. If not managed correctly, the use of feature flags could inadvertently increase risk rather than mitigate it.
When are Feature Flags Worth It?
That said, feature flags aren't without their use cases. For certain critical features, the overhead and complexity can be justified. Examples of this might include core signup flows where any disruption is unacceptable, or vital backend processes that need to run seamlessly.
In such cases, there are alternatives that can offer most of the benefits of feature flags without the added complexity. One such technique is the "odds and evens" method, where processes are run for every odd or even-numbered customer, job, etc. This simple hack allows for phased rollouts with less complexity than typical feature flags.
The Bottom Line on Feature Flags in Early Stage Companies
The theory behind feature flags - enabling safer and more flexible releases - is undeniably attractive. However, like many theories, its application can be challenging, especially in early-stage startups where agility, simplicity, and speed are paramount.
Before embracing feature flags, consider the potential complexity they add to your release process and whether that complexity is truly necessary or justified given your team size, agility, and the nature of your features. In some cases, simpler techniques like the "odds and evens" method might serve you just as well, if not better.
As a startup grows, the utility of feature flags may change. However, in the early stages (under $10M), it's worth carefully considering whether the added complexity will provide the value it promises or instead become an unnecessary hurdle in your path to success.