Build or Buy

As an engineering or product manager, your mission is to deliver quality software on time. You are looking to make your team fast, productive, and and more coordinated. Most importantly, you want your customers to love your product.Feature flagging can help you achieve all these goals: on time delivery, with less risk, for a product your customers love.

Professional developer tools are both the foundation and scaffolding for building successful products. Without team collaboration tools, issue tracking tools, IDEs, and version control systems, your team would find it challenging to release timely, high-quality software. To facilitate and improve product development, managers must inevitably decide whether to build developer tools in-house, purchase a platform, or maintain the status-quo.

The tradeoffs for each option depend on your resources, time, and internal expertise. Sometimes it’s better to build in-house, other times it’s more resource-efficient to purchase existing solutions. When it comes to feature flag driven development, companies who try to build internal platforms tend to face the following challenges:

In summary, with a completely scalable platform like LaunchDarkly, you can easily roll out features, see the reaction on your users, and either continue rollout or completely shut off.

• Total cost of ownership: Homegrown tools are built to exist and serve a particular function, but with new business demands comes the cost of upgrades. There is a high cost to ongoing maintenance, both in time and money. Technical debt accrues over time due to engineer turn-over, product neglect, and evolving product demands.
• Unknown And Evolving Scope: Developing an internal product requires planning, resource allocation, and preparing for the unknown. Because feature flagging platforms are relatively new, it can be difficult to accurately define the scope and construct a solution for needs across not only engineering but also product groups.
• Minimum Viable Functionality: Internal developer tools are generally not built for usability, scalability, or cross-team support. They are built to solve an immediate pain point or provide minimum viable functionality as quickly as possible.
• Polyglot Language Support: Companies typically use multiple languages in their stacks and might adopt new languages in the future. This requires an adaptive feature flagging system that can handle the nuances of each language without compromising performance and stability.
• Compliance: Company-wide internal tools require access controls, audit logs, and potentially custom permissions to ensure that functionality is controlled at an appropriate level.

Feature flagging is a straightforward concept that becomes difficult to manage on an enterprise scale. It’s easy to manage one feature flag by modifying a configuration file, but when you have multiple feature flags across different environments, it’s harder to keep everyone in sync in a compliant fashion. Facebook has a feature flagging system called Gatekeeper that took years to build, using limitless engineering resources. Wrapping one feature with an if/else is just the start, an enterprise-grade feature flagging systems require:

• An intuitive dashboard that an entire organization can use.
• Access Control Levels to allow different functions (Developers, QA, Product) separate rights.
• Complex business rules for flags – “Can we roll this out to 10% of customers in Canada?”
• Cascading flags – “This flag is evaluated only if another flag is true.”
• Multivariate values – “If an end user is on a different device version, behave differently.”
• Auditing for who changed a flag when.
• Performance & targeting analytics.
• Speed in microseconds
• Scale to handle millions/billions of flag evaluations
• 100% uptime and redundancy

Companies that have built internal feature flagging tools (e.g. Google, Facebook, and Amazon) dedicated large teams of engineers and DevOps experts to build the platform, and continue to use full-time engineers to maintain and scale their systems.

Let’s look at the required inputs and expected outputs for an enterprise feature flagging platform.

Inputs

• Software Engineering
• User Interface Design
• Feature Flag Expertise
• Time (Months, Years)
• Money
• Infrastructure
• Outputs

Outputs

• Managed Continuous Delivery
• Risk Mitigation
• Feature Lifecycle Management
• Faster Release Cycles
• Percentage/Incremental Rollouts
• User & Group Targeting via Attributes
• Developer Coordination
• Visibility for Non-Developers
• Cross-Team Support

When making the build versus buy decision, it’s important to ask the following questions:

• Can I divert my engineers from building the core product to building an internal tool?
• What are the actual and opportunity costs of devoting engineering time?
• How will I maintain the system in the long-run? Will I need to devote engineers full-time to managing the platform?
• What infrastructure will I need to ensure system reliability?
• What redundancies will I need to build?
• Once it’s built, will it actually work at an enterprise level (speed, uptime, scale)?
• How long will it take to build, test, and integrate the system into our continuous delivery process?

When purchasing a feature flagging platform, you want to make sure that you are integrating a well-tested and proven solution. You want to ensure that the feature flagging platform is:

• Stable
• Multi-language Compatible
• Scalable
• Intuitive
• Well-Supported

The platform should also allow you the flexibility to integrate feature flag driven development across teams and across products (web and mobile), either through an on-premise/private instance or managed cloud platform.