LaunchDarkly gets $8.7M to put the right features in front of right users
techcrunch.com
techcrunch.com
We’ve been so pleased w/ LD that we agreed to do a case study with them if you want to take a gander: https://launchdarkly.com/casestudies/lanetix.html
Also, we implemented most of LD in a 24-hour quarterly hackathon we hold at my company: https://engineering.lanetix.com/2016-02-22/how-lanetix-does-...
Hope this helps!
we implemented most of LD in a 24-hour quarterly hackathon we hold
What's the breakdown of 'most' vs the remaining? 80/20? Alternatively, if 'most' was implemented in 24 hours, how long would it take to implement the rest?
From these two statements, I get the impression that either
(1) LD is cheap to buy to begin
(2) 'most' should be taken with a dash of salt
But then after a few minutes... I kinda got it. I think this is a great tool for marketing, biz, and product management in organizations where the overall organization structure is kinda messed up and they cannot convince development to do things right. Which is 90% of companies. Very similar to hiring external management consulting services: since nobody in the company is capable to organize this.
So in short - LaunchDarkly will do well.
That has nothing to do with why feature flags exist. No amount of planning or perfectly written software will give you insight into how your customers will react to your feature. I'd rather release something to 5% of my customers, see how it performs in the wild, make adjustments accordingly, and only then release it 100% along with any marketing initiatives that support it.
If teams use feature flags to release untested/unprepared code, that's their prerogative and is a perfectly acceptable use case if the business is amenable to those risks.
I've lost count over the years of how many features I've seen significantly modified after user feedback, or altogether cancelled because it was determined the long-term maintenance cost wouldn't be worth it vs. adoption/traction.
With that said, you can do it yourself. For example here is my elixir/redis feature toggle library https://github.com/securingsincity/molasses and a feature toggle library in PHP that I've used and contribute to https://github.com/opensoft/rollout
Code-wise, this seems like a pretty straightforward problem. I'm surprised there aren't more competitors.
They are a little more pricey than we'd prefer, but we're happy.
nb: I work for LaunchDarkly, if it wasn't obvious from my comment.
Disclaimer: I don't work at the company anymore, but I worked on a previous incarnation of the tool.
Here are a few key benefits I've seen as an avid user of LaunchDarkly, that are end up costing a lot to build on your own:
- ability to have people outside of engineering control who gets access to what features. Specifically, product management should have control over what features are available, and they probably don't want to go into a dev console to make the changes. Sure, you could build a UI on top of home grown FFs, but why spend valuable time on this?
- rules-based user targeting -- rather than embedding ugly logic into your code about what type of user should be served a feature, you can handle most of that within LaunchDarkly's UI. For example, we have some restaurant groups that have 100's of locations. Rather than setting values at the location or <gasp> user-level, I can simply set a flag at the restaurant group level and that automatically propagates to the user level. Sure, you could build this hierarchy into your homegrown tool, but I guarantee doing that in a very flexible manner won't be a slam dunk, and you'll soon find that you will want to change it and have to invest more time on something that may not be core to your business.
- custom rollout -- you can roll out by % of users or user properties. For instance I can roll out to 10% of users that are in Rhode Island, US. Did you really add this to your homegrown FF service? I hope you didn't tell your VCs that if so...
- centralized feature flag service -- we leverage across dozens of components, and use feature flags centrally on our cloud servers and on 1000's of agents installed inside our customers' locations (and on hardware that we don't own). Since LaunchDarkly uses server-sent events (SSE) this introduces no additional latency in making network calls to a central server. Changes to users and flags are sent streaming, seamlessly, behind the scenes, with minimal network impact. This key infrastructure decision that the team at LaunchDarkly made has given us confidence of using feature flags wherever we could feasibly imagine them without having any adverse impact to us or our customers. Oh, did you remember to build that into your homegrown FF solution?
- multivariate flags -- LaunchDarkly supports multivariate flags. For example, we throttle data transport for some of our remote agents. We can control this centrally so that certain agents only send back certain amounts of data (e.g. 1MB, 5MB, 10MB per batch of data sent). This actually extends the concept of FeatureFlags -- there are discrete variations within a single 'flag'. Don't forget to build that into your homegrown solution too.
- feature flag chaining -- you can specify a prerequisite for a feature flag. For example, for a rebranding of an entire website, you could have individual feature flags for each page, and then have a 'big bang' flag that does the entire thing at once. This allows you to test and manage 'micro features' but then turn on the 'major feature' easily.
- they have thought a lot about the technical debt that feature flags can introduce. How often have you added a feature flag only to not use it again or forget to remove it? It can make your code base ugly in a hurry. LaunchDarkly has analytics that help you identify usage paths as well as 'flag the flag' so you can be more conscious about what is a temporary vs permanent flag. This might not sound like much, but it prevents questions later about 'can we remove this flag' without causing impact. You've future proofed your homegrown solution to grow into this too, no doubt.
- organizational visibility and integrations with third party services -- LaunchDarkly has many integrations already built into it. For example, we use it to post to our #product channel in slack, so we can see when a new feature becomes available and when someone changes an existing flag/adds users to it. This has made communication about features much less time intensive because anyone can see the current state of a feature. You didn't really build a Slack integration or create a bot just for your homegrown feature flag service, did you?
If you think you'll eventually be in the place where what I've spoken about would be helpful, I would strongly suggest you consider a service like LaunchDarkly early in your development so that you can focus your energy on the right things and take advantage of the hard work that LD is putting into their service.
We have gotten some requests for desktop SDK support, which would work more like the mobile or JS clients work, since there is a single user at a time, and the key used to get flag values must not leak any proprietary business info or details about other users. This is on our roadmap, so the funding will help here :)
An external service for boolean flags seems a bit overkill to me.
Edit: I read the first comment, looked at the features, and read the case studies: I am guilty of vastly oversimplifying what this does. The value proposition is still not right for my particular business, but at my previous job at Big Company, we had a custom rollout dashboard that didn't have most of these features (targeting groups, percentage rollout), and it still saved us many hours of development time.
Obviously is must be more impressive than it sounds - people wrote 9 million in checks.
However, I acknowledge that I may be vastly oversimplifying, and am not knowledgeable enough about LaunchDarkly to speak so brazenly about how I could do it myself. My main point is that as a small web development company, we have this feature in our builds already, and it only cost us a couple hours of development time to implement it.
With frameworks that go far beyond AB testing for most backends why would you lock into something like optimizely:
Of course, you should evaluate the options for your situation. For many use cases, an open source library will solve the problem just fine. For larger projects/teams, something like LaunchDarkly will be a better fit.
Any of us could build this ourselves in a few minutes for a local app, but to scale up to millions of users is very tough.
As far as Scale is concerned we routinely see request timeout to LD and then suddenly a user loses a FF they previously had. Our cached value for the FF expires and then LD fails and then my customer is mad
Please do post it, I'd love to help out anyway I can.
I think I can do feature flags faster.
Disclaimer: no relation, just playing devil's advocate.
It's a SAAS tool and you could build it? Well hot damn, you must be a programmer!
I'm stunned by how many refuse to learn from Gmail (mailserver), Dropbox (intra-company sharing), Slack (IRC), AWS (servers), the list goes on.
What a severe waste of your potential. Someone else has built a better version than you will ever build because they are focused 100% on this one specific problem. Even better - the cost of building, serving, and maintaining it are amortized across a larger user base with a small profit tacked on top.
If you can't use a SAAS because of privacy/security concerns, totally get it, that's how it goes some times. If you refuse to use one because of not-built-here syndrome, you're wasting company resources and making yourself less valuable along the way. Companies pay for solutions, not this-was-built-here tools.
It's a perfectly rational pricing strategy, of course, but it can sometimes feel like one of those economics experiments: "A colleague receives 100 dollars and is asked to split it between him and yourself. If you disagree with the split, neither of you gets anything. Your colleague proposes to give you 10 dollars and keep 90 himself. Do you choose to accept the 10 dollars, or would you prefer both of you get nothing?"
Also, your examples are about ancillary utilities, but let's say you're a data scientist and you decide to build your own A/B testing system instead of using one of the existing services out there. If you add up all the dev time and maintenance time the homegrown system will probably be way more expensive, but on the other hand building it might teach you a bunch of intangible skills that make you a better experimenter and that could be worth the expense if the company expects employees to stick around for a while.
Having said that, personally I still prefer to just pay for something. But I'm not at all stunned when other people do decide to roll their own tools.
Recognize that there's a cost to pulling in 3rd party libraries, much less 3rd party services, into your project. It's not just the cost to integrate, but of figuring out failure modes. The offering can evolve to no longer serve your use case. They could deprecate the API, causing you to have to update current, and past, projects. Google can buy them and shut them down.
If you take this approach for everything someone has a SAAS for, you could spend more time responding to their changes than evolving your own product. Been there, done that - it isn't fun.
Obviously there is the benefit of having a team of people who are constantly making the system better and more robust. I think with ML there would be a serious value proposition here, e.g. allow a learning system to automatically roll out a new feature for you, and reverse the rollout if things appear to be going poorly. Even the worst case of built-it-myself syndrome would not engineer a custom feature flag system that far.
Let's say you want to open a restaurant. Now sure, you could go out, start a farm, open a steel mill and a mine to make all your knives and cutlery yourself, cut down timber and construct the entire building yourself, make your own furniture, etc.
Really, you could do all of those things. And I think that's the state of the software world, about 10 years ago. Hell, maybe even today, compared to 10 years from now.
These days, we're rapidly moving to a world where probably 95% of what a typical company needs -- code hosting, scaled relational storage, execution grids a la Docker on ECS, load balancers, A/B testing, SMS infrastructure, feature flags, etc. can be bought off the shelf, for a fraction of what it would cost to do yourself, and at much higher quality than a single individual could do.
It's a natural outgrowth of the increase in developer salaries, in fact, the two go hand-in-hand: labor productivity is up a lot because of these tools, and the incentive to buy cheap off-the-shelf stuff is higher than ever, vs. paying for expensive, scarce, flighty developer labor.
I do wonder what this means about starting companies, though. I think software will increasingly move toward an industry where, like owning a Burger King, you have to raise capital (rather than just doing everything yourself) because so much of what you need has to be bought, and peoples' standards are so high. And yet, it is more optimal to have to raise capital, because anyone can get money; not everyone has the skills/talent/know-how to build complicated software. Buying is less risky than building.
No longer is it enough to home-roll a webserver: now you need to launch from day 1 with a native mobile app on multiple platforms, everything has to work on any size of display, it all has to be bug-free, high-design, autocomplete-text-boxed, perfection, from day 1.
This whole "it's getting so cheap to ship a v1" is malarkey, IMO.