Build or Buy?
If you’re thinking about implementing feature flags on your team, you’re probably asking yourself: should my team be building their own feature flagging tool, or should we invest in a third party solution?
It’s a fair question to ask. After all, engineers can build almost anything you ask them to. But just because they can, doesn’t necessarily mean they should. We’ll explore the pros and cons of Build vs Buy here.
Time and Resources:
If you work for a software company on a product or engineering team, your primary goal is likely to ensure that your team is delivering high quality software to your users on time. You’re constantly looking for ways to increase productivity on your team and ship features more frequently.
Feature flags can help you with all of the above, but if your engineering team’s primary goal is to actually ship features to your end users, you may not want to burden them with the task of building and maintaining a feature management solution on their own. Ideally, your feature management solution is put to work for your team; not the other way around.
Having a feature management solution in place can improve your team’s release cadence and productivity, but if they’re spending too much time maintaining and building the solution they’ve built rather than actually using it to release features, you’ve probably wasted a whole lot of time and effort to build something that’s not actually effective or contributing to your growth.
Cost Analysis:
Would you rather spend money on a third party solution with a dev and support team that will work to fix bugs, maintain the system, and continuously improve its features for you? Or would you rather spend money hiring and training more developers to build a solution on your own team, and constantly compensate them for maintenance of the system rather than actual feature releases?
The choice is yours, though teams often find that investing in a third party solution is actually more cost-effective than constantly pooling money and resources into a homegrown solution.
Think about it: you can only make money on code that’s been released. And you hired your developers to release code–not build a feature management solution.
Remember What Your Developers Are Good At:
Our developers are trained and highly skilled in developing feature management software. Your developers were hired to build software in your industry–whether that be retail, gaming, healthcare management, etc. Asking your developers to focus on building yet another internal product that helps you deliver your actual end product is spreading your already constrained resources even thinner.
Let our developers handle the feature management, and let yours get back to doing whatever it is they do best.
Managing Flags at Scale:
We’ve mentioned this a few times throughout this guide, but it’s especially important to consider if you’re deciding between building your own solution and buying one:
Getting started with feature flags is usually a very seamless process. Any engineering team can do it. It can be as simple as adding three lines of code and boom–you’ve got a feature flag! But as your flag usage increases and your organization grows, managing them at scale becomes increasingly difficult.
Not to mention, a proper feature management solution that actually enables your growth requires a lot more than just a few feature flags. To maximize the output of your solution, most companies will need:
- An intuitive UI that even non-technical users can navigate
- Full SDK support across multiple languages,
- 100% uptime
- Flags evaluated at zero latency
- Complex targeting rules & user segmentation
- Different flag types for different releases
- Proper auditing so that your team knows who made a change, and when
- Integration with your existing tech stack
And the list goes on.
It’s certainly possible to build a solution with all of those features, but does that sound like something you want to try and build? Well, let’s see how one of the world’s largest organizations ever did it: Meta.
Meta has a homegrown feature management solution that took years to build, countless engineering resources, and still (to this day) requires a large team of engineers and DevOps leaders to maintain.
This wasn’t a project they sprung on their own developer team on top of their daily tasks and tickets. This was a project they hired an entirely new team of engineers to tackle.
Additionally, this project wasn’t terminated or considered “complete” after the solution was built. It’s an ongoing feat to ensure the system remains free of bugs and functioning properly for the rest of their developers to use.
Are the following inputs worth the following outputs of building your own solution?
Input required to build a solution:
- Software Engineering Expertise
- UI Design
- Feature Flag Expertise
- Time (to build & to maintain)
- Money (hiring new devs, or compensating your current ones even more)
- Infrastructure
- Onboarding new team members to the platform
Input required to buy a solution:
- Money to invest in the solution
- Onboarding new team members to the platform
At the end of the day, you know your team best. But you’d need to be pretty confident that your own developers have the time and resources necessary to build something like this before springing the task on them.
We’ll leave you with some solid questions to ask yourself before making the final decision:
- Does it make sense to divert my engineers’ focus from building and improving our core product to building a homegrown solution?
- What will the short-term impact be on the company if I task my engineers with this project? The long-term impact?
- How much time and how many resources will be required to maintain the system in years to come?
- What is my long-term goal for using a feature management solution?
- Will we be able to build a solution that performs at an enterprise level?
- Will we be able to easily onboard our product team, key business stakeholders, and new team members?
Click here for more information on how our team at DevCycle evaluates the pros and cons of Build vs Buy!
