Launch HN: DevCycle (YC W14) – a feature flag platform built for developers

Hi HN, Cobi here, Co-Founder of DevCycle (https://devcycle.com). DevCycle is a feature flag platform focused on developer experience, speed of delivery and long-term maintainability.

To give the platform a shot, anyone can sign up and use DevCycle for free here: https://devcycle.com

Here’s a general platform demo video if you’re interested: https://www.youtube.com/watch?v=bZD-pyKGwR4

Feature flagging is a technique that lets developers switch features on or off in a software application without redeploying it, enhancing testing and rollback capabilities. At their core, feature flagging platforms solve the problem of separating production code deploys from feature releases to users. While DevCycle solves that same general pain, we also aim to solve core problems in developer experience and code maintainability that hold developers back from fully adopting feature flagging into their workflow.

In traditional feature flagging platforms, extended flag usage increases code complexity over time. Most engineers with feature flagging experience are worried about the build-up of stale flags and their code being filled with unnecessary conditionals. Dealing with this problem is important because if an engineer is worried about this increasing complexity, they are likely to avoid using feature flags.

We came upon this problem when we were building Taplytics, the startup we joined YC with. We experienced it not only from our own struggles with feature flagging and transitioning to continuous deployment but also from our time spent with Taplytics customers who were often on the same journey.

Given this experience, we developed DevCycle with a few core differences in how we solve these problems.

Features, Not Just Flags: Many in-house and competitive feature flag systems operate on the simple idea that features exist in a binary state - they are either ‘ON’ or ‘OFF.’ In reality, software is never this simple. DevCycle treats features the same way you do in every other context, by attaching highly-extensible remote configuration to every feature in your product, allowing multiple flags to be combined under the context of a single feature and configured together.

Developer Experience: To get the benefits of feature flagging you need broad adoption by all developers touching a codebase. Our primary goal is to provide the best developer experience possible. Providing tools and integrations so we can get out of developers’ way. For example, to address the problem of long-running feature flags that build up over time, we offer developer-facing features to easily track, detect (deploy pipeline actions), and eventually remove unnecessary technical debt (CLI code cleanup commands).

Given that we are building this as a developer-first product, we’d love your feedback on whether our approach better fits your workflow and any other thoughts on our solution. Thanks so much!

How do you differ from LaunchDarkly?

(DevCycle Co-Founder & CTO here) The truth of the Feature Flagging market is the vast majority of engineering teams aren't using a third-party tool for Feature Flagging. Most teams are using an internal system (Environment Variables, Database flags, S3 files ect.) or not doing any feature flagging. The potential for the Feature Flagging market is as large as any other developer tools market, and the challenge is to build a product with a better developer experience that encourages the adoption of feature flags and integrates with team's workflows.

We've been in the A/B + Feature flagging space for about ten years with our visual A/B testing-focused product Taplytics (W14), so I'd say we have lots of experience running Feature Flags + A/B tests at scale. We've learned a lot from our customers over the years and were excited to build DevCycle as a green-field project from those lessons. If you are interested, try it out and we are always open to direct feedback.

Hey, thanks for the question.

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.

Really interesting take on your experience with experimentation / feature flags and wanting it to be more stateful in code. I assume that follows the more Terraform-like infrastructure as code approach, which certainly makes sense to rollout infrastructure changes. We have a V1 of a Terraform provider where we hope to enable more control through terraform to manage infrastructure changes directly, but you are correct that has yet to be our core focus. Another way we hope to expose that state outside of our UI is building out a great CLI, which we are actively working on.

Our primary usecase has been working with product development teams who have adopted Feature Flags as part of their workflows, using DevCycle to help them deploy features faster / safer to their end users, even deploying continuously as we do. Generally, customers integrate DevCycle into their Websites / Mobile Apps + API servers to control those feature deployments. We have had a couple of customers use us at the infrastructure layer. One of the best use cases I've seen is in a proxy service controlling the rollout of a new infrastructure stack. I'd love to dig into this use-case deeper and see how we can better support it in the future, "Ops" flags are one of the flag types we are looking to support.

I would say that for customers looking to disconnect the deployment of code from the release of features, our approach where you can "release" features at any time has many advantages over "git-ops" style configurations. But certainly, for Ops use-cases where you are controlling infrastructure changes, we are believers in "git-ops" and use it ourselves. The challenge comes with how to connect those two deployment styles effectively.