It’s a common question, and there’s no one-size-fits all answer. But whatever you choose, there’s a common realization many people have after they start using feature flags:
Feature flags are just the beginning, over time you’re going to need a lot more functionality
So, let’s start with the beginning.
Basic uses of Feature Flags
At their most basic, Feature Flags deliver these benefits
- Faster development cycles. By decoupling code deployments from feature releases, you can avoid long-lived feature branches and reduce the need for synchronized releases across different teams.
- Canary releases. This is a technique you can use to test a feature in production. Partially turn on a flag to a small set of users to measure its impact. Once the impact has been measured, it can be turned on for a wider audience
- Continuous integration. Flags enable your dev team to incrementally merge changes into the main branch, but keep new features dark, reducing the merge conflicts that happen when multiple engineers are working independently.
- Kill switches. Turn off poor performing features
- Launch time-sensitive features. Some features, like a Mother’s Day promotion, should only live for a short time. With flags, you can turn them on and off
- Incremental rollouts. Deploy features to a certain percentage of users to get their feedback
- Beta/opt-in groups. Give new features only to users who are part of early access programs
On their own, these are transformational benefits. But managing these flags is yet another aspect to consider.
Managing your Feature Flags
For a team to use flags, they need a system to manage them. That system should
- Have a dashboard that shows the status of all flags
- Have user roles so that users can only modify flags they have access to
- Have 100% uptime and flags that can intelligently roll back
- Scale to whatever usage you need
- Support any language you require
Obviously, you could build to address each item, and many have. However, lots of teams have opted to buy a system due to the ongoing costs of maintaining in-house systems.
Going beyond Feature Flags (hint: experimentation)
So we’ve seen that Feature Flags have many benefits. But today, they have to do more. Facebook, Spotify, Uber & Airbnb have proven that experiments powered by feature flags are the backbone of great products.
What if your flags could give you
- The power to release features to 100% of your users with confidence that your metrics are safe or improving
- The power to find the cause if your KPIs rise or fall
- A wholistic view of the entire ecosystem of your metrics and how they move over time
This type of insight is powered by experimentation. And building that in-house is complex, time consuming, and goes beyond the basic functionality of flags.
That’s where Statsig makes the difference. We go above and beyond the benefits of feature flags and help you run hundreds, thousands, or even tens-of-thousands of experiments automatically & simultaneously so you can build products people love.
But let’s say you’ve decided to build your own anyway. No worries, it might be the right answer for you. But, there are a few things to look out for.
Things to keep in mind before you build your own
Now it may make sense for you to build your own system. Convoy built their own system because no other vendor on the market could meet their unique requirements. There are scenarios where it makes sense to build your own.
But there are costs involved, and we recommend you consider the following questions:
- What are the costs of spending your engineering resources on an internal system instead of building features that deliver value to your customers?
- What kind of infrastructure is required for you to keep your system online?
- What happens if an architect of your internal system leaves your organization?
Technical considerations if you build your own
A final set of questions regards your infrastructure
- How will ensure maximum uptime and redundancy? How will you handle server failure?
- How are flags evaluated in an offline situation?
- Is your service performant? If every flag computation requires a server call, you may significantly slow your service
- Can your service scale to millions of events?
As always, projects that seem simple to begin with are actually far more complicated.
Unleash is by far the most popular open-source feature flagging project, and we recommend you take a look at this before building your own.
What to look for in an Enterprise Feature Management System
Beyond the basic features that all vendors provide, what else is there to consider?
- Does the vendor empower your entire team to get insight? Most charge for additional team members, which prevents everyone in your organization from making data-driven decisions.
- Is it easy for anyone to run experiments? The only way to really know how your features are performing is by measuring their impact on your metrics. Each Feature Flag should be considered an experiment, and you should be able to see how each feature changes each metric.
- Does the pricing make sense? Are you restricted by number of the number of seats? The number of active users? Pick a system that grows with you.
At Statsig, our goal is to help you use data to build better products. That’s why we make it easy to run experiments, see the impact of features on KPIs, and understand the combined effect of changes over time. We believe that by giving everyone on your team these insights, you’ll make better decisions and ship features users love.