By the time a lot of teams realize they may want a feature flag tool, they already have one. For a lot of companies, feature flags tools are built internally first. Sometimes this means pretty robust solutions, built off open-source tooling or existing internal rules engines – and, sometimes it means simple configuration switches stored in a file in the repo or database.
There’s nothing wrong with this journey, because feature flags are a way of working that usually requires some initial clear use cases for you to jump in and then, over time, you find they subtly change the entire way your product teams work. Those initial use cases, though, can seem pretty simply to solve yourself.
So, when is it time to jettison your existing homegrown solution? Should you build that solution to begin with? Or is feature flag software (such as Harness Feature Flags) actually better from day one? Let’s take a look.
Why Do You Even Want Feature Flags?
Before we jump into the classic build vs. buy discussion, let’s quickly recap some of the reasons you may have ended up even considering implementing feature flags – or something that looks like feature flags that you may not be calling feature flags just yet.
I should say up front that I don’t think the individual problems feature flags initially solve are actually the most powerful part of working with them. Over time, a team that uses feature flags simply becomes more efficient. You will ship more, worry less, and it will be easier to communicate and plan with your teammates across your product teams. Feature flags are really a way of working, once you get used to them – but that’s not necessarily what you’re going to be searching for on day one.
Initially, teams come to feature flags for a few reasons:
- Can we test this new feature with a few of our users in an easier way?
- Can we make it easier for our PMs to add users to new features?
- Is there any way we can incrementally roll out a change in production?
- Is there a better way to test the impact of changes or new features than constantly deploying and rolling back?
Feature flags are primed to help with all these problems by letting you separate deployment from release, letting you work dark behind flags, and light up code paths when you’re ready for a limited section of your audience that you can define.
Why Internal Teams Want to Build a Feature Flagging Tool
When teams bump into any of those problems, it’s not uncommon for engineers to say something like, “Oh, we can just create a config file to do that.” Flash forward a year or two, and those same teams will have a hodgepodge-built feature flagging tool solving whatever use cases have come up in the meantime in whatever way the person with the most free time wanted to expand the system to solve it. And that’s fine! There are tons of problems in your average engineering team that are solved exactly the same way.
At some point, though, the question gets asked: “Would buying a feature flag tool be better?” Given that we sell a feature flag tool, it’s easy to say yes – but there are some pretty good arguments for building your own solution too.
“Most of what the commercial feature flag tools have is overkill.”
You may feel like for your simple needs, you really won’t make use of all the bells and whistles of a feature flag tool. Your system is working fine, and you don’t really see your organization getting into the more complex workflows the vendors are advertising.
“We can make it do exactly what we need.”
Another great argument is that custom tooling solves your problem, not everybody’s problem. You can cut the fat, customize the experience, and make sure that you are not compromising on how you want the tool to work.
“It’s cheaper.” Or, “It’s free.”
Why pay money for something that you can knock out yourself with a few days or weeks of work? No engineering team finds itself with too much money to spend, so any money you don’t spend here is money you can spend somewhere else.
Why You Should Consider Buying a Feature Flagging Tool
The first thing I want to say is these are not bad arguments. For some teams in some contexts, we don’t even want to refute them. Build vs. buy is a complicated choice, and teams that are so far solving their own problem can, in fact, have pretty good experiences.
But, we do think there are some pretty big issues with the build path, as well as a lot of latent opportunities that teams taking that route are giving up to do so.
Complexity in Building and Maintaining a Feature Flag Platform
Like most solve-it-in-house choices, you could pretty easily lay out a graph showing that the ROI of your internal solution diminishes the more the system is used by your organization. For the first few flags and users, you are saving thousands of dollars.
But what happens when you have dozens or hundreds of flags, different types of users that you want to limit access to, flag-created tech debt to manage, and multiple environments to serve flag states in? Before you know it, you’re spending a lot of time expanding your solution, and the cost and time of maintaining and running it just keeps inching up.
Commercial feature flag solutions, such as Harness, handle these problems – and handles them with teams dedicated to security and performance at scale.
The more mature you get with flags and the more people in your organization use them, the higher the bar will be for how easy, fast, and reliable you want them to be. A poor experience becomes limiting and discourages the use of the system.
With an in-house built system, the experience will almost always degrade as complexity increases, because it is usually impossible to justify the time and resources needed to create a truly great developer and user experience.
At Harness, we center the developer experience end to end. It’s what our designers do, it’s what our engineers do, and it’s what our PMs do. A flag page that loads instantly, vs one with latency and a design that’s easy to use, rather than discouraging people to want to deal with it, will increase the ROI (and velocity) that your team gets out of flags vs a homegrown solution.
Best Practices and Workflows
One of the things engineering teams rely on their tooling for is to help uplevel them. Tools can make smart choices, learn from a large user base, and help accelerate all their customers by bringing best practices, good habits, and innovations in workflows to customers. Meanwhile, individual teams may not have thought about these features – but could certainly benefit from them.
When you use an internal solution, you can solve your problem, but you won’t leverage the industry-wide knowledge base around how to design, build, and use feature flags effectively to create great engineering outcomes. That’s exactly what Harness does when we build our solutions.
Management, Governance, and Security
One freaky thing about feature flags is that they let folks change things in production. For real users. Instantly!
That can set off a lot of alarm bells with different people. Security, management, PMs, and others all might not love that level of access, and – if not done carefully – can see it as a threat rather than as a superpower.
With Harness, we’re able to design exactly the features that organizations need to make this safe. This means RBAC, audit logging, global policies and templates, scheduling and approval workflows, and more. Most homegrown solutions don’t have this, or if they do they are a mess of middleware scripting connecting to your various business systems. That scripting needs to be maintained and refined constantly, and you need to convince everyone to trust it.
Try Before You Build or Buy
With all of that said, the real litmus test should be your experience. Try the tools out, consider how you’d replicate some of that functionality yourself if you don’t have an in-house solution, or if you do, start trying to assign cost to some of the invisible overhead factors like time, maintenance, security, and scalability.
In most cases, we think it makes sense to buy a feature flag tool vs building one. Building is often a stronger case when there is less robust commercial tooling, or when the problems are more bespoke. Neither of those things are true about feature flags anymore.