How to build an in-house feature-flag system?

If you're thinking about building your own feature flag system, you're not alone. Many teams prefer the control and customization that comes with an in-house solution, especially when their needs are straightforward. But as feature flagging becomes more critical to your workflow—whether for gradual rollouts, complex targeting, or cross-team collaboration—the system you build can quickly become difficult to manage.

This article is here to help you navigate that decision. We’ll walk through the different options for building a DIY feature flag system, covering everything from simple setups like environment variables to more advanced options like using a database or building a UI. And, if you find that your needs are more complex than what DIY can offer, we'll explore when it might be time to consider a third-party provider like Tggl, which handles the heavy lifting for you.

Step 1: Environment variables

The simplest way to set up feature flags is by using environment variables. This method is quick to implement and great for things like a global kill switch, where you might need to disable a feature across the board in a hurry.

Advantages:

• It’s dead simple to set up. You can create an environment variable and toggle it on or off as needed.
• Ideal for global flags like a kill switch that affects your entire application.

Drawbacks:

• Every time you need to update a flag, you’ll have to go through your tech team. This can slow things down, especially if non-technical teams need to be involved.
• Not ideal for targeting individual users. It’s tough to manage feature flags for specific customers or segments with just environment variables. You will probably need to list ids or emails in a coma separated string and parse it at run-time.
• You’ll need to redeploy your app every time you change the value of a flag, which can be cumbersome if your release process isn’t made with that in mind.

Environment variables are a great starting point, but as your needs get more specific—like wanting to enable features for certain users without redeploying—you might need something more flexible.

Step 2: Values in a database

The next step up from environment variables is storing feature flag values in a database. This approach is especially useful when you want to enable or disable features for individual customers or specific groups of users without redeploying your app.

Advantages:

• You can easily target individual users, allowing for more personalized feature rollouts. It is just a matter of updating the user in the database.
• Unlike environment variables, there’s no need to redeploy your app every time you want to change a feature flag. You can update the flag in the database and see the effect instantly.

Drawbacks:

• You’ll still need to go through the tech team to update or manage the flags, which might slow things down.
• It’s not ideal for global flags, like a kill switch. For those, you’d need to update the flag for every individual user in the database, which is not ideal.
• It doesn’t support more advanced features like random percentage rollouts or complex targeting rules based on location, plan, time, or other variables.

While storing values in a database gives you more flexibility than environment variables, it may not the best solution for managing more complex feature flag setups.

Step 3: Building a UI

To take things a step further, you could invest in building a user interface (UI) for managing feature flags. This option allows anyone in the company—not just the tech team—to toggle flags, making it much easier for non-technical teams like product or marketing to control feature releases.

Advantages:

• Non-technical teams can manage feature flags without needing help from developers.
• It offers better visibility and control over all the feature flags in the system, making it easier to track and manage them.

Drawbacks:

• Building a custom UI requires a significant upfront investment in terms of development time and resources.
• Even though the UI simplifies flag management, it still inherits the limitations of the database solution: you can’t do complex targeting (like percentage rollouts or targeting based on location or time) and it's not ideal for global flags like kill switches.
• The initial setup can be a lot of work, and if your needs change, you may have to continually invest in maintaining and upgrading the system.

Building a UI is a great step forward, but it’s not a complete solution if you need advanced features like complex targeting or collaboration across teams.

Step 4: Building a system with random traffic splitting

For teams looking to experiment with feature rollouts & A/B Testing, random traffic splitting is an essential tool. By dividing users into random groups, you can control how a new feature is exposed to different sets of users, making it ideal for A/B testing or gradual feature rollouts. Internally building a system that supports random splits offers greater control over the feature release process and helps in running more accurate tests.

Advantages:

• You can control the exposure of new features to different user groups, allowing for effective A/B testing or gradual rollouts.
• It provides a powerful framework for experimentation, enabling your team to test new features on a small percentage of users before rolling it out more widely.

Drawbacks:

• Building such a system is not trivial. Implementing accurate random traffic splitting requires a strong understanding of how to properly divide users, avoid bias, and ensure consistent results.
• It’s complex to implement, especially when you factor in the need to maintain randomness, avoid conflicts, and handle edge cases like ensuring users see the same version consistently across sessions.
• Maintaining this system over time can become an ongoing effort, requiring regular updates and tweaks.

If you’re considering this approach, I recommend checking out this guide on how to run an accurate A/B test experiment to get started with the basics of traffic splitting.

When to consider a third-party provider?

For more complex use cases, a third-party provider like Tggl can save you time and effort. Third-party tools come with all the bells and whistles that DIY solutions often lack—like advanced targeting, collaboration features, and built-in management tools for technical debt.

When should you consider a third-party provider?

• If you need to roll out features to specific user segments based on criteria like geography, time, or device type.
• When you want to enable random percentage rollouts to test new features on a small group before releasing them to everyone.
• For collaboration across teams, allowing multiple stakeholders (like product, tech, and marketing) to safely manage flags without accidentally breaking anything.For example, Swan’s journey with Tggl shows how teams can seamlessly implement feature flags across departments and handle complex use cases like technical debt management.
• When you need to manage technical debt, with features like monitoring, flag clean-up and tagging to keep things organized.
• If you need built-in tools for auditing, reviews, and setting up approval workflows, which are essential for compliance and security.

With Tggl, you also get the advantage of a platform designed to scale with your needs. As your team grows and your feature flagging use cases become more complex, having a provider that offers out-of-the-box solutions can save you from spending valuable development time maintaining an internal system.

Conclusion

Building your own feature flag system can start out simple, but as your product and team grow, the complexity of managing feature flags increases. While using environment variables or storing values in a database can work for basic setups, these solutions start to fall short when you need more flexibility, like targeting specific users or collaborating with non-technical teams. Even if you go the extra mile to build a custom UI, you might still run into limitations with advanced use cases like percentage rollouts or complex targeting rules.

That’s where third-party providers like Tggl come in. They handle the complexity for you, offering everything from advanced targeting options to collaboration tools and automatic technical debt management. By using a solution like Tggl, you can focus on building your product, knowing that your feature flag system can scale with your needs.

Ultimately, the right approach depends on your specific use case. For simple, short-term needs, a DIY solution might work. But as your product matures, investing in a third-party provider like Tggl will pay off in time saved and smoother feature management.