> 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
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) -…
Sounds like most of those problems are just problems with microservices generally. Adding a service makes this worse.
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.
I thought it's satire. Like "/dev/null as a service".
> 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.
That seems like code which should check customer account information, not a feature flag thats turned on or off.
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/ .
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?
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.
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) -…
> 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.
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?
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.
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) -…
Do we need a feature flag-aaS if we have a monolith and easy way to add columns to user table?