Build vs. Buy

As engineers, we love to build! As such, it's completely natural to learn about feature flags and then think, "Yeah, I could build that." And, in fact, we did build a very simple implementation earlier in this book (see Going Deep on Feature Flag Targeting). But, building your own feature flags system is probably not a great use of your time (or your company's time).

Feature flags are deceptively simple. So much of what we see—the branching logic within our application code—is just the tip of the iceberg. There's much more below the surface that goes into keeping your feature flags available, reflecting configuration changes in near real-time, and allowing your team to manage feature flag state across multiple environments.

Assume that the cost of building your own implementation is going to be high—higher than you anticipate. And then, ask yourself if this kind of work generates a competitive difference for your company? Meaning, does building your own implementation give you a competitive advantage when compared to buying an existing implementation?

The answer is probably, No; but, it's a conversation worth having internally. After all, feature flag services are not cheap. And, the more your team grows, the more expensive these offerings become (based on a per-seat pricing model).

Each SaaS vendor is going to be different; but, consider this list of common features:

• Project management - a bounded collection of feature flags.
• Environment management - a bounded set of targeting rules.
• Feature flag management - defining variants and targeting rules.
• User management and permissions - who can manage your feature flag dashboard.
• Insight and analytics - which variants are being expressed in your application runtime.
• Cohort management and segmentation - defining reusable targeting rules.
• Change management and approvals - tracking and gating changes to feature flag state.
• Software Development Kits - libraries already authored (and battle-tested) for all of your programming languages.
• Code insights - finding and removing feature flags in your application.
• Synchronization speed - the time it takes for configuration changes to be reflected in the application runtime.

The need for synchronization speed: We don't always think about speed as an explicit feature; but, when considering feature flags as a means to mitigate runtime performance problems, the speed of synchronization can be critically important. In fact, the speed of synchronization can become the difference between an annoying performance hiccup and a full-on system outage.

As with so many things in programming, it's a matter of return on investment. If you buy a solution, is the value it delivers worth the explicit cost that you're paying? And, if you build a solution, is the value it creates worth the opportunity cost that you're giving up—the time you could have spent building other differentiating features for your customer?

Have questions? Let's discuss this chapter: https://bennadel.com/go/4555