A Decision Continuum: Deciding Between Feature Flagging Software vs. an In-House Solution
To build or to buy, that is the question.
If we’re honest, feature flags are extremely simple at their core. Any engineer can write a Boolean and add basic logic to their product.
This is exactly where many teams start, and for good reason. An in-house solution is often a valid choice, especially at first.
As your feature management approach needs to level up, you might start needing more from your flags. This is when most teams start to weigh up building or buying feature flagging software.
To help you weigh up whether you should build vs buy feature flags, we’ve created a simple (and hopefully intellectually honest) continuum and set of factors to consider for you and your team.
The Build or Buy Continuum
Building or buying sits on a continuum, with building on one end and buying on the other:
- Build:
On the build end of the continuum, it makes sense to build it yourself. Building and managing flags might take the same amount of time as implementing a third-party vendor. Or managing flags internally might just make more sense for your use case. - Buy:
On the buy end of the continuum, bringing on a feature flagging tool frees up engineering time and makes your release management simpler.
Figuring out where your team sits on this continuum can help with making the right decision for your needs.
Note: Your position and needs might change over time. We've also put together a guide for knowing when it's time to move from in-house flags to feature flag software.
We sat down and thought about the reasons why people should and should not buy from a feature flagging company. There are a few use cases on each side, and six main factors that can help you decide for your team.
Use Cases for Building
The first step is to analyse your current workflows, flag use cases, and any problems you have. It pays to do this before going straight to feature flag software. Look at your releases, your team, how sprints are going, and how long issues are taking to get resolved.
A couple of example use cases for building in-house:
- You have very simple flag requirements - Say you’re a small team working with a single language and/or application. Or you just need to hide a few simple features with flags. In either case, it really doesn’t make sense to move to a third-party vendor.
For example, if you’re working with single booleans like the following:
if (flagsmith.hasFeature('my_cool_feature')) {
myCoolFeature();
}
- You have highly specific/niche use cases - You have a very niche use case for your flags, like working with a less-commonly used language like COBOL. Working with your existing infrastructure makes more sense than migrating, which could move your team’s focus away from critical tasks.
Use Cases for Buying
A few use cases for buying a tool:
- Your flag requirements are scaling up - You’re working with more teams, more languages, more customers. You need a tool that can handle growth.
- You’re migrating from a monolith architecture to microservices - Using a feature flagging tool is a good choice when you’re managing lots of applications and change points.
- You’re releasing for mobile applications - If releases and publishing take a while for your team, mobile apps make this worse with the approval times. Feature flagging software can make this process a lot less crazy to manage.
Buy or Build: Six Factors to Consider
- Data Protection and Security
Build in-house:
In-house solutions inherently come with a lot of control. This can be important if your company needs strict control over the codebase, or if you need a high level of security.
Feature flagging tools:
If this is a concern, going with a feature flagging tool with on-premises hosting can help. Deploying on-premises feature flags gives you maximum security and control of your flags, with minimal service-to-service latency.
Flexible deployments are important for letting you choose how to run your feature flags—whether SaaS, Private Cloud, On-Prem. You can prioritise data control, management of your infrastructure, and security with self hosted on-prem or private cloud solutions.
(As a related aside, latency/performance can be better with home-grown tools, but there are ways to solve that with some vendors.)
- Feature Management Complexity
Build in-house feature flagging:
If your feature flagging requirements are simple and work within your existing workflows, it makes sense to stick to in-house. On the other hand, if your needs are highly specific or niche, it may also be better to stay in-house. (Though it does pay to contact a vendor to see if they can meet your requirements.)
Feature flagging tools:
Feature flagging vendors are great when you need to do more than simply hide a few features. They let you get rid of some environments and test in production. They help you move to trunk-based development so you can continuously integrate and don’t have teams waiting to deploy while getting stuck waiting for signals to release.
They’re built to handle more complex flag needs and prevent stressful releases with monster code.
- Cost-Effectiveness: Development and Maintenance Costs
Build in-house:
Back to the continuum; if you have simple flag requirements, building and maintaining an in-house tool can be more cost-effective than implementing a third-party vendor.
If your needs become more complex, though, building and maintaining an advanced in-house tool can take up a tonne of resources—and get pricey. Think about implementing all of the authentication, managing server uptimes, and lots of management that takes you away from product development.
Feature flagging tools:
As you grow, using a feature flagging tool frees up resources that would otherwise sink into managing an in-house solution. Engineers can get back to building and testing products. This means happy engineers who can get back to cranking out code.
- Having the Tools You Need
Build in-house:
Building in-house means maximum customisation. This can be really important if your company has unique needs that aren’t met by out-of-the-box feature flagging tools.
Feature flagging tools:
Feature flagging tools come with advanced features and integrations that meet the needs of most use cases—and can be difficult to replicate in-house. Unless your needs are particularly niche, you will likely be able to find a vendor that meets your criteria.
- SDK Language Updates
Build in-house:
If you’re working with one or two languages, an in-house option might be easier to manage. If you’re working with multiple languages, maintaining SDKs can become a lot of work; patching security updates from libraries, new frameworks, new languages etc.
Feature flagging tools:
Feature flagging tools ship with SDKs for a bunch of different programming languages and are kept up to date in terms of security and associated language frameworks.
- Scalability and Volume
Build in-house:
If your team and needs are smaller, an in-house solution will likely be easier to manage.
The difficulties of building and maintaining an in-house option grow as you scale, though. As your customer-base, team, and volume of requests grow, home-grown systems can become strained.
Feature flagging tools:
Feature toggling tools are built to handle scale and make releases less stressful. To manage multiple teams, multiple applications, and multiple languages, feature flagging tools make your life a lot easier.
Concerns Around Vendor Lock-In And Changing Systems
It’s very easy to feel locked into a feature flagging vendor. This factor alone can put people on the build end of the continuum, or prevent them from switching.
If you’re making the migration to a feature flagging tool, you want to make sure it’s the right one. And that you won’t get stuck with things like price hikes.
Using an open source tool can help. It gives you transparency and means you can just look at the code if you have any concerns.
Flagsmith is open source and invests in OpenFeature for this reason. OpenFeature provides a connection point where people can switch feature flagging software with ease. This takes the claws out of a feature flagging tool and means customers can choose—or switch to—the right solution for the right reason.
Conclusion: Finding What’s Right For You
If we come back to the continuum from the beginning: Choosing whether to go with in-house feature management or feature flagging software comes down to your company’s specific needs, time, and resources.
Check out open source feature flags and look at codes and repositories if you're on the fence. Or if you're ready to move from in-house flags , here are some onboarding steps for feature flag management tools that can help.
If you want to try out Flagsmith, create a free account here or contact us. We’re happy to talk through any questions you have, and to offer our honest insights to help you make the right decision for your team—even if that means not using us!
More Reading
Daniel Engelke, former CTO of BibliU, wrote an article about his decision-making process for building vs. buying feature flags here
.webp)