There’s a point in the life of every organization where something completely breaks down.
It doesn’t necessarily have to be software that crashes; some of the most momentum-killing experiences in your career will come as a result of systems and processes dissolving under the weight of scale. In many cases, a contributing factor of something buckling under the weight of new demands is the mistaken belief that what worked yesterday will still see you through tomorrow.
What’s frustrating about these moments is that perhaps there’s a collective understanding that something is broken and it’s causing lost opportunities, and yet there remains the question of how to move forward quickly without falling too far behind.
When a team or organization arrives at this crossroads, software solutions are frequently targeted as a remedy. If you’re at an organization that is already capable of developing software, it may seem logical to try and fix the problem yourself with some homemade solution, an open source option, or a combination of both.
From Kafka to Kubernetes, there’s a rich history of organizations building internal solutions that have far exceeded anyone’s original expectations. On the flip side though, there are potentially an infinite amount of examples of organizations trying similar tactics to construct internal solutions that result in little more than some heated internal arguments and some dry-erase markers thrown at the wall.
In this article, we’ll walk through some of the considerations that organizations weigh when making the choice of either building their own solution internally (DIY) or buying it from a vendor. And to keep things from getting too amorphous, we’ll keep our example focused on a hypothetical software company that wants to deliver faster and more continuously with a feature flagging platform.
Cost
Think of how your boss will look at you when you say you’ve saved the company thousands of dollars per month by simply building a feature management tool on your own. After all, a homegrown feature flagging tool can be customized specifically to serve your team’s current needs. But, like a bespoke suit or dress for your wedding that’s tailored to your exact measurements at the time, things change. A year from now, will that outfit still fit exactly the same?
That’s why it’s important to consider the full spectrum of expenses of developing your own feature flag solution as well as its ongoing maintenance. It’s going to take a lot of dev energy to even get the tool off the ground, and when something breaks, how quickly can it be fixed and who is the point person to correct it? It’s important to quantify all this information and think about it in terms of the amount of currency that’ll be invested upfront and in the future.
Then, there are the issues that arise when the folks who architected the solution leave the organization and take all their knowledge with them. True, open source options may be available, but they generally lack support and struggle with longevity issues in a similar way to just building one yourself.
And do you really want to be personally responsible for all the onboarding and change management initiatives around this new solution?
Buying it
Before you go looking for vendors, hopefully, you will have estimated the amount of money in dev hours and general logistics you’d be looking at if you did decide to go DIY or open source. That’ll help you go into any exploratory phases with a better understanding of cost.
While not free, the upside of the right feature flag vendor should exceed anything you could possibly hope to accomplish through DIY. After all, these vendors focus 100% on feature flag platforms. Take some time, learn your options, and compare them to what you could accomplish on your own today and years from now.
At the very least, you’ll know the vendor will spend a lot of time and resources managing your flags so that you can reallocate your development efforts back into your core product. It’s one less thing for you to think about, but ultimately if you make the right choice, it’ll be a long-term investment in your company’s future without major financial implications.
Functionality
DIY
This is often where the comparisons are starker. Lots of companies attempt to throw together an in-house solution, and things might work amazingly for your immediate team. Problems can arise, however, when folks outside of your team need access.
For instance, it can be very challenging to develop a feature management solution that also acts as a resource for engineering, product, and beyond. This is where a lot of scope creep can make itself known. You might, for instance, be able to get a killer feature management solution up and running through DIY or open source. However, if you can’t demonstrate its value to other teams, let alone give them easy access, you’ll likely end up with multiple different versions of a feature flagging solution to address differing needs. Not only will that mean more work for your team, but the outcome will essentially be several different internal systems that perform similar functions and all require regular maintenance.
An adaptive, accessible system that can integrate with new languages/technologies – without compromising performance, stability, and security – is difficult to maintain in addition to your other responsibilities. Beyond core functionality, admin controls like role-based access, audit logs, and custom permissions must be considered.
Buying it
Let’s be honest, homemade systems are not generally built for usability, scalability, or cross-team support. Open source solutions face the same challenges and are typically put together with minimal considerations made for the developer experience.
A modern feature management system will need to be able to perform all of these duties in order to even stay competitive in the market. Also, you’ll likely have plenty of external resources for support from your vendor should issues arise. It’s tough to put a price on peace of mind in this respect.
Experience
DIY
As already mentioned, internal feature flagging solutions can be customized to your team’s exact specifications, which is fantastic. Who knows more about your team’s needs than your actual team? But while a home-built software solution can get you pretty far, they’re usually not built for the long haul. As mentioned previously, areas like accessibility, scalability, and cross-functional support will eventually drag you down. Open source software might provide better usability, but if your company has eyes on growth, most solutions of this variety aren’t built to last. One other thing to consider: creating a feature flagging solution is not your organization’s core competency. We’ll assume your company has some competition in the marketplace, so what sorts of things will be put on hold while your devs are building out an internal solution?
Buying it
If you’re purchasing a software solution, you may need to compromise on some things. True, it might not be a custom fit for your team, but if you invest in the right one, it’s going to take care of your team as it grows and scales. You’ll be able to relax knowing that there are teams of people working on improving your experience day and night. Your vendor should want to make feature management a first-class experience that’s flexible, secure, and powerful. And, because they view feature flagging and release management as critical infrastructure, their platform will continue to expand to suit your needs now and in the future.
Final thoughts
No one can tell your company what the best path is when it comes to build or buy, because each situation and team is so different. That’s why it’s important that the answer comes from within your organization. The thing that does help is doing your research upfront so you at least know your options. Hopefully, this article has provided you with some consideration points when you reach the build vs. buy debate at your organization.
Just remember: what you don’t want to do is get into a situation where you’re spending more time trying to build a better solution than you are on the actual main product you’re supposed to be working on.
