This product is probably not intended for me but at this stage I'm not even sure I know what a feature flag is any more.
I thought feature flags were just toggles so you could turn features on and off. I wouldn't know how to implement those as anything other than code. Or why you would need an external service.
Some flags are meant to be enabled for specific customers, on-demand, depending on what type of contract is signed, under NDA and so on. Over time, many department that aren't "engineering" need to be able to change some flags. That doesn't imply your culture is broken.
Flags at this level are not simple toggles, they will embed some business logic - that's the custom logic and attributes that I mentioned. This is standard fare in Statsig, Split, Launchdarkly, and most other commercial providers. You then collect metrics for each group to monitor features.
You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.
If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.
> product, not eng, will start managing the flags at some point and needs easy access
That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.
If you're not running A/B tests, doing gradual rollouts, don't have a metrics platform, and haven't had to go beyond simple on/off status, probably not.
A lot of "engineers" nowadays don't know the concept of per-user/customers configs and how to build/expose them to non-technical staff.
The main appeal of feature flags is simplicity and being a low-hanging way to apply per-customer/user configuration, few platforms allow true a/b testing (amplitude comes to mind but I'm sure there are more).
Feature flag can (usually does??) have another meaning, as a technical feature rollout mechanism, so you can roll back quickly without a deployment. A way to manage risk on teams that make hundreds of commits/deploys a week. You can then often send a certain % of traffic through the feature or not to look for early warnings.
I don't like feature flags for config. Just build a config system into the product UI - a settings page basically! That might have some bits you configure as the site owner, and some that are self-service.
You are right, feature flags are just toggles but the devil is in the details. When the product scales you would want to test things internally or with a close group of people on prod before you make it public (beta releases). Sometimes you would want to release features at a specific time (Apple, Figma product launches). Sometimes you would want to test if A is working better than B (A/B testing typically in eCommerce sites). Sometimes features are location-specific (Different content for different countries, netflix does this). Let's consider a scenario: You have a team of 10 engineers working on 5 different features. They merge their feature branches to a main branch which gets deployed at the end of the release cycle. Now, if one of those features isn't working as expected, the engineers will have to roll back to the last deployment which won't have any of the 5 features. With feature flags, this could be avoided by developing all features behind a feature flag.
Likewise, while the idea of sticking the determination of whether a given feature is enabled or not in a REST service would make sense, it's not at all clear why you'd ever want to farm that out to another provider, apart from the rare case when you're making a static website with no backend at all.
If you have any kind of back-end infrastructure, it'd seem trivial to implement this yourself. Doing it yourself also allows you to make the feature flags more controlled, e.g. by some flag associated with the current user such as opting into experimental features.
For efficiency, I'd also want to batch a bunch of such flags together, so e.g. when a use logs in they get a list of enabled features that gets cached locally, rather than having to query each and every one via REST.
So I'd echo the question, what problem is this solving?
One of the key aspects of feature flag systems is enabling A/B analysis, measuring the impact of features on metrics like click-through rate, session duration, and revenue. This doesn’t seem to be mentioned in the highlights. Is the product targeting these kinds of insights?
Why does this need to be a dependency? In my view feature flags are core enough not to be outsourced to a third party. Although, there are companies using libraries for "isEven" so there might be a market for it.
That's a fair point! Basic feature flags are just toggles, true and false. But they quickly become complex as you onboard new customers and scale. You need percentage rollouts to make sure things are working before everyone starts using the features. It only makes sense for engineers to spend time building actual features and testing them in production rather than spending bandwidth on building a feature flag management tool or managing the service for the same. This is a typical build vs buy debate. :D
Aah! That's a miss from my end. I had it on my previous landing page. It is 100k requests a month. But, I am not adding any cap right now. I monitor the system all the time so if it goes above the free tier limit significantly I will notify.
Cool product and great landing page. This is quite off topic: how did you make the code animation in the Feature Flag as Code section? I reminded me of prezi.com (with their slide animations). Would love to know!
That was the main pain-point I faced in the orgs I have worked with. When I came to know about the OpenFeature I was instantly gravitated towards building this on open standards.
This product is probably not intended for me but at this stage I'm not even sure I know what a feature flag is any more.
I thought feature flags were just toggles so you could turn features on and off. I wouldn't know how to implement those as anything other than code. Or why you would need an external service.
What problem is this solving?
Writing your own logic to handle flags is trivial at first, especially if you're running a monolithic app, but quickly grows in complexity:
- distributing flags to multiple services
- broadcasting updates
- caching rules
- audit logs
- product, not eng, will start managing the flags at some point and needs easy access
- custom logic for gradual rollouts, A/B testing
- custom attributes support (used in evaluation)
- managing multi-variant flags
- supporting multiple platforms (backend, frontend, native apps, services, jobs) and evaluation strategies (eager server-side evaluation vs shipping a client-side engine)
There are quite a few open-source options like Growthbook, Flagsmith, go-feature-flag, and Unleash that you can check out for comparison.
> product, not eng, will start managing the flags at some point and needs easy access
How to tell you have a broken engineering culture.
Some flags are meant to be enabled for specific customers, on-demand, depending on what type of contract is signed, under NDA and so on. Over time, many department that aren't "engineering" need to be able to change some flags. That doesn't imply your culture is broken.
I think most would say that’s configuration, not feature flags. The differences can be subtle but I at least don’t think they’re the same thing
That seems like code which should check customer account information, not a feature flag thats turned on or off.
Flags at this level are not simple toggles, they will embed some business logic - that's the custom logic and attributes that I mentioned. This is standard fare in Statsig, Split, Launchdarkly, and most other commercial providers. You then collect metrics for each group to monitor features.
You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.
Activating only for beta users or opted-in users is a supported use-case on OpenFeature using the dynamic context (https://openfeature.dev/specification/glossary#dynamic-conte...).
If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.
Sounds like most of those problems are just problems with microservices generally. Adding a service makes this worse.
> product, not eng, will start managing the flags at some point and needs easy access
That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.
Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?
If you're not running A/B tests, doing gradual rollouts, don't have a metrics platform, and haven't had to go beyond simple on/off status, probably not.
I have a bias but I would still suggest using feature flags even for on/off functions. Example of how I do it:
https://x.com/ctushr/status/1949215574980272177
I can see the others in the build/buy debate, but how's metric platform connected to this?
A lot of "engineers" nowadays don't know the concept of per-user/customers configs and how to build/expose them to non-technical staff.
The main appeal of feature flags is simplicity and being a low-hanging way to apply per-customer/user configuration, few platforms allow true a/b testing (amplitude comes to mind but I'm sure there are more).
Feature flag can (usually does??) have another meaning, as a technical feature rollout mechanism, so you can roll back quickly without a deployment. A way to manage risk on teams that make hundreds of commits/deploys a week. You can then often send a certain % of traffic through the feature or not to look for early warnings.
I don't like feature flags for config. Just build a config system into the product UI - a settings page basically! That might have some bits you configure as the site owner, and some that are self-service.
Statsig and launchdarkly are the one that come to mind for me.
You are right, feature flags are just toggles but the devil is in the details. When the product scales you would want to test things internally or with a close group of people on prod before you make it public (beta releases). Sometimes you would want to release features at a specific time (Apple, Figma product launches). Sometimes you would want to test if A is working better than B (A/B testing typically in eCommerce sites). Sometimes features are location-specific (Different content for different countries, netflix does this). Let's consider a scenario: You have a team of 10 engineers working on 5 different features. They merge their feature branches to a main branch which gets deployed at the end of the release cycle. Now, if one of those features isn't working as expected, the engineers will have to roll back to the last deployment which won't have any of the 5 features. With feature flags, this could be avoided by developing all features behind a feature flag.
Likewise, while the idea of sticking the determination of whether a given feature is enabled or not in a REST service would make sense, it's not at all clear why you'd ever want to farm that out to another provider, apart from the rare case when you're making a static website with no backend at all.
If you have any kind of back-end infrastructure, it'd seem trivial to implement this yourself. Doing it yourself also allows you to make the feature flags more controlled, e.g. by some flag associated with the current user such as opting into experimental features.
For efficiency, I'd also want to batch a bunch of such flags together, so e.g. when a use logs in they get a list of enabled features that gets cached locally, rather than having to query each and every one via REST.
So I'd echo the question, what problem is this solving?
I had the same question after quickly reading the docs.
I am probably not directly an intended user but I sure would be glad to understand what this is (as an amateur dev)
You can checkout my reply to the same comment. I have explained it in terms which is easy understand for everyone.
One of the key aspects of feature flag systems is enabling A/B analysis, measuring the impact of features on metrics like click-through rate, session duration, and revenue. This doesn’t seem to be mentioned in the highlights. Is the product targeting these kinds of insights?
These features are in pipeline. It is currently targeting the developers to help them with rollbacks and release management.
Why does this need to be a dependency? In my view feature flags are core enough not to be outsourced to a third party. Although, there are companies using libraries for "isEven" so there might be a market for it.
That's a fair point! Basic feature flags are just toggles, true and false. But they quickly become complex as you onboard new customers and scale. You need percentage rollouts to make sure things are working before everyone starts using the features. It only makes sense for engineers to spend time building actual features and testing them in production rather than spending bandwidth on building a feature flag management tool or managing the service for the same. This is a typical build vs buy debate. :D
I thought it's satire. Like "/dev/null as a service".
Love the simple landing page! How big is the free tier? The pricing slider seems to show that you pay $39 for anything more than 0 requests.
Aah! That's a miss from my end. I had it on my previous landing page. It is 100k requests a month. But, I am not adding any cap right now. I monitor the system all the time so if it goes above the free tier limit significantly I will notify.
Cool product and great landing page. This is quite off topic: how did you make the code animation in the Feature Flag as Code section? I reminded me of prezi.com (with their slide animations). Would love to know!
Hey, Thanks! I recorded it using https://screen.studio/.
Thank you! I’ll have a look at it.
Great product glad its built on open standards!
Love that it is build on open standards, i hate vendor lockins. Will pitch this at my org with a POC :)
That was the main pain-point I faced in the orgs I have worked with. When I came to know about the OpenFeature I was instantly gravitated towards building this on open standards.
Great product! Actually a big point that I've seen in enterprises.
Thank-you! Do let me know how was your experience if you to use it.