LaunchDarkly is a feature flag management system that allows you to scale up. You get an intuitive UI that non-technical users can control feature flags with - for example, a Product Manager can turn on functionality. We also give you access level controls and audit logging - allowing you to control who can change which feature flag and get visibility on these changes. As well, we offer SDKs for multiple languages so you can use feature flags consistently, across mobile and web. When you’re ready to use feature flags at scale, we hope you’ll use LaunchDarkly.
Would love your feedback about how you’re using feature flags already, and what you’d expect to see from a feature flag management system.
* A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways
* A distinction between a true feature flag and what I call a "release" flag, ie, a feature that's not yet fully built, but that will not be optional once fully built and released, so its flag goes away at some point.
Also, btw, do you have an API for the flag creation itself, not its use, ie a addFlag()/removeFlag() API?
We have more coming, including an ability to mark "permanent" flags that should never be removed.
The product is built API-first-- everything in our UI is driven via our own REST API. Docs are here: http://apidocs.launchdarkly.com/
Can there be a feature switch that is configured not based on users, but on owner/admin's choice alone?
More importantly, how do the LD SDKs help with the issues mentioned in the "Implementation Techniques" section of Fowler's essay - things like avoiding conditionals, DI, etc?
re: conditionals, DI: our SDKs focus on the base technique (flags based on conditionals), but it's possible to wrap that core with higher-level approaches like DI, etc. We're considering going down that path, but where it makes sense to do so, and not have to re-implement higher-level wrappers for every framework out there. So, e.g.-- in Ruby, I can see us providing higher-level APIs specific to Rails.
Dependent feature flags are also an interesting problem-- we don't have a solution to that yet, but we do spend a lot of time thinking about feature flags, and I hope we'll have something on that front soon :)
 How much is premium support?
What's the flow like for a developer creating their own environment? I'm a little concerned that asking developers to visit a third party site/be connected to the internet to use feature flags locally be pretty inconvenient, especially if the developer is working offline. Would you consider adding a simple server implementation that could run locally and do feature flagging on a per user basis (rather than rolling out to percentages, to prevent misuse)?
You can also provide a default value that will be used if the network is not available. You can read from a config file to drive this if you need to, to allow devs to specify the flag value when offline. This is what we do for our dogfood environment (prod, staging, and dev environments all talk to dogfood, but dogfood doesn't have another LaunchDarkly to talk to).
Hope that helps!
And of course, we'll launch new features behind a flag. I'll admit that we've had two or three occasions where we had to hit the kill switch after a deploy, so I'm rather glad we had a LaunchDarkly for our LaunchDarkly.
 here's a shot of our dogfood instance: https://twitter.com/jkodumal/status/717786744750477312
It's basically the same market as Optimizely.
Let us know if you have any questions.
Disclaimer: I'm a front-end developer at LaunchDarkly.
nb: I'm an engineer at LaunchDarkly
Though the thing I'm picking up might be more the fact that this company didn't just launch today. I.e., they're not showing us something new today. Their product has been out for, what, at least a year? So if "Show HN" is ok here, then really any company's social media person can just repeatedly post links to themselves...