Six Questions to Ask Your Dev Team Before Building Your Own Feature Flagging Tool

Thinking of building your own feature flagging tool?

Here are 6 questions to ask your team before diving in.

Feature flags have become an essential tool for dev teams, enabling them to roll out new features and experiments with confidence and increasing their deployment frequency. While feature flags offer numerous benefits, almost any development team preparing to use them will likely weigh two options: building their own feature flags, or investing in a third-party tool. 

Since the decision to build your own tool requires careful consideration, we’ll explore six important questions dev teams should ask themselves before building their own feature flagging tool.

1. What are our specific requirements and goals? 

Before diving into the development process, it’s important to define your team's unique requirements and goals for a feature flagging tool. Consider the specific functionalities, integrations, and scalability needs that are essential for your use case. Evaluating your requirements will help you determine if existing third-party solutions align with your needs, and if building your own is even doable. 

Note: many dev teams who choose to build their own feature flags merely build feature toggles that allow them to turn their features on and off quickly, when in reality, feature flags are more than toggles alone. Feature flags provide a multitude of functionalities, such as A/B testing, advanced user targeting, gradual rollouts, and more. It’s rare to see a home-built solution with all of these functionalities. 

2. What existing feature flagging tools are available? 

You should survey the existing market before committing resources to build a custom tool. There are many feature flagging solutions available, each with its own set of features and benefits, both commercial and open source. Once you decide exactly what you want to use feature flags for, you should assess whether any existing tools meet your requirements and can be tailored to your needs. Leveraging an established third-party solution can save valuable time and effort, which we’ll talk about next. ⬇️

3. What are the costs and resources required for building our own tool? 

We get it: you’re an engineer, and engineers can build just about anything. But just because you can, doesn’t always mean you should. Oftentimes, teams are surprised at just how much goes into building and maintaining their in-house feature flagging solution. You may see the initial cost of a third-party solution and think you can build something just as good for “free” – but it’s not actually “free” when:

• It’s taking your developers’ time and resources away from building your core product (aka the only thing your company can actually generate revenue from.)
• You’re essentially paying your developers a full-time salary to build that tool. (Most teams can use DevCycle for as little as $25 per month…)

Ultimately, the cost of building your own feature flags goes far beyond merely building them. You need to consider the financial investment required for development, testing, documentation, and ongoing maintenance, as well as the opportunity cost of diverting engineering resources from core product development.

4. Do we have the necessary expertise and experience? 

This is a key question to ask and answer honestly.

Assess the skills and knowledge within your engineering team to determine if they possess the necessary capabilities. Developing and maintaining a custom tool requires a deep understanding of feature flagging concepts, version control systems, security, and scalability. A lack of expertise can lead to inefficiencies and potential vulnerabilities, and you likely won’t realize the full potential of feature flags if they’re not built well. 

To put it another way: Sure, our team of engineers could probably find a way to build a working bicycle if they were asked to. But the bike they build wouldn’t be nearly as effective or well-built as a bike built by an engineering team that only builds bikes. You wouldn’t build your own bike, so why would you build your own feature flags?

5. How customizable and extensible does our tool need to be?

Consider the level of customization and extensibility required for your feature flagging tool. Many solutions offer a wide range of configuration options and integrations to cater to diverse needs. Evaluate if these off-the-shelf solutions can be tailored or extended to meet your specific requirements. 

6. What is the long-term maintenance plan? 

(And who do you want your team to yell at if (when) things break?)

Building a feature flagging tool is just the beginning. Maintenance, updates, bug fixes, and compatibility with evolving technologies and platforms require ongoing attention. Consider the long-term commitment and resources required to maintain a custom solution. Third-party solutions relieve this burden by providing a community of users, regular updates, technical support, and compatibility with industry standards. Should something go awry, let your CTO yell at our support team, not you. 

How does DevCycle compare?

As a quick recap, let’s see how a third party feature flagging solution like DevCycle addresses some of the bottlenecks in-house solutions have:

In-house feature flags are often merely feature toggles that allow dev teams to simply turn a feature on and off:

DevCyle’s feature flags come with a full-suite of capabilities that give you utmost control over every release. Your own dev team likely can’t build out functionalities like realtime updates, A/B testing, gradual rollouts, and advanced user targeting, so you won’t really realize the full potential of feature flags with a homegrown solution. 

Expertise and experience:

‍Like we said above, building a proper feature flagging tool requires a level of expertise and experience that only dev teams whose core job is to build feature flags would have. Let our team do what we do best (build really good feature flags) so that your team can do what you do best (build your core product really, really well.)

You’re paying your devs a full time salary to build your feature flagging tool:

‍Most teams can get started with DevCycle for as little as $25 per month. Check out our pricing plans here.

‍Integrations:

‍If you want your home built solution to work well with your current tech stack, you have to build out all those integrations... on top of building the feature flagging solution and on top of building your core product. Third party tools like DevCycle come with fully-built out integrations with most major development tools that you love and use every day.

Wrapping up

So, before diving headfirst into building your own feature flagging tool, take a step back and ask your team these questions to get a clearer picture of what lies ahead. We’re not saying you can’t build your own (you can… and some teams do). We’re just saying we’d be shocked if you built a more functional and efficient feature flagging solution for as low-cost as DevCycle. Still unsure whether building or buying is the right choice for your team? See the power of DevCycle’s feature flags for free today.