[mattbrewsbytes]

This isn't a huge ordeal to DIY. A database table with some fields (name, on/off, dates) and a module to call that checks the db. A simple UI/API to CRUD those rows.

If it's a SaaS, how does your app function if the SaaS is unavailable?

[shoo]

I've never used a full blown whiz-bang solution for feature flags, but when I stared at the launch darkly API one day it seemed as if:

* feature flags were generalised as certain class of functions that made an on/off decision based on certain inputs, and the definition of these functions could be sent from the server to client services that had integrated the feature flag library. Functions could be refined at runtime etc -- generalised notion of toggling a toggle.

* there appeared to be capability for services to maintain local cache of the feature flag / expression rules so it didn't introduce a hard failure point on external service. Functions uses to make toggling decisions could be evaluated with inputs locally.

Take this with several grains of salt, never used it, I might be misremembering and it might not actually work this way

[yoz]

(I'm a Developer Advocate for LaunchDarkly.)

Both of these are true. See also my reply to the parent comment - you don't even need a local cache, since all flag evaluation calls should include a fallback value.

[yoz]

Hi - Dev Advocate for LaunchDarkly here.

There's the local cache feature mentioned by shoo below, but more simply, there's also a fallback in the flag eval function, which looks like:

    flag_value = LDClient.variation("flag-identifier", context_object, fallback_value)

... where fallback_value is the value to be returned if there's nothing else available.

As for DIY-ing it, I wrote about the pros and cons of rolling your own here: https://launchdarkly.com/blog/feature-management-platform-bu...

(TL;DR: Sure, you could build your own super simple one in a few hours, but it wouldn't have most of the features that make feature flags useful, and why bother when there are open source implementations already?)

[mattbrewsbytes]

I've built one in a few minutes, not hours. Our main requirement was releasing tested code to production ahead of when other interacting pieces are ready (other API's, UI changes, etc.) Usually there is an API contract in place with the other party at this point and feature flags help a CI/CD process keep things moving instead of sitting on a feature.

In Rails if you have Active Admin, you just define the migration for feature flags and you are basically done. AA gives you a UI which you can protect with roles. Put a couple methods on the model and then you can toggle features anywhere in your code.

Our use case is very small, feature flags get deleted after all the moving parts are shipped and working. I'm sure your product has many more use cases and capabilities.