The primary differences stem from a difference in focus. We believe that LaunchDarkly is a great first-mover in the space and has done well in their validation of the space. Their focus has traditionally been on the enterprise, which manifests itself in a product focus on things that large enterprises require, like tooling around governance.
For DevCycle we believe feature flagging is about more than just enterprise risk management, and is actually more deeply related to the way in which teams build and ship code together. As such, our focus is on the developer experience and mapping our product more closely to how developers actually work.
This manifests itself in a few key areas:
1. We believe that all of the interfaces that engineers interact with need to be delightful including SDKs, APIs, CLIs, docs, etc.
2. We've built DevCycle from the ground up to better match to a concept of building features, with coordinated releases vs distinct and disparate feature flags. What this means is that we natively bundle feature flags within the concept of a feature, so that a feature and all of its component flags can be rolled out in coordination without the need for workflow automations.
3. It should be as easy to remove our flags as it is to create them, to reduce the cognitive load and complexity of feature flagging over time.
4. All aspects of the platform from the way its built, to the way it is priced (seat based pricing vs usage based pricing) should make it as easy as possible to have all engineers on a team be able to work together on feature flags, as opposed to creating friction and complexity that reduces the number of people that interact with flags on a daily basis.
I hope that helps, if I can clarify further let me know.
I have a feeling someone else is going to respond with some other points so I wanted to touch on something particular:
From my view, I just personally think most folks should be using feature flags and a continuous deployment cycle in general. With that in mind, a lot of what we built was to make it more accessible. We focused on an easier to understand UX, and building tools that were easy to interact with.
But most importantly in that line of thinking, and a major differentiator in my eyes, we tried to make as much of our platform un-gated as possible.
So all of our features are available to anyone regardless of their plan (outside of anything that requires a custom setup or something truly enterprisey).
This means that all of our integrations are freely available too.
The primary differences stem from a difference in focus. We believe that LaunchDarkly is a great first-mover in the space and has done well in their validation of the space. Their focus has traditionally been on the enterprise, which manifests itself in a product focus on things that large enterprises require, like tooling around governance.
For DevCycle we believe feature flagging is about more than just enterprise risk management, and is actually more deeply related to the way in which teams build and ship code together. As such, our focus is on the developer experience and mapping our product more closely to how developers actually work.
This manifests itself in a few key areas: 1. We believe that all of the interfaces that engineers interact with need to be delightful including SDKs, APIs, CLIs, docs, etc. 2. We've built DevCycle from the ground up to better match to a concept of building features, with coordinated releases vs distinct and disparate feature flags. What this means is that we natively bundle feature flags within the concept of a feature, so that a feature and all of its component flags can be rolled out in coordination without the need for workflow automations. 3. It should be as easy to remove our flags as it is to create them, to reduce the cognitive load and complexity of feature flagging over time. 4. All aspects of the platform from the way its built, to the way it is priced (seat based pricing vs usage based pricing) should make it as easy as possible to have all engineers on a team be able to work together on feature flags, as opposed to creating friction and complexity that reduces the number of people that interact with flags on a daily basis.
I hope that helps, if I can clarify further let me know.