Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: DevCycle (YC W14) – a feature flag platform built for developers
56 points by cdrux 11 months ago | hide | past | favorite | 34 comments
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!




Something I love about the experiment tooling I've used at a few places now (Thread, Google) is the fact that state has typically been stored in source control. i.e. not just the usage of flags in code, but the rollout/experiment definitions, the state of how much traffic is allocated to each branch, eligibility requirements, etc. This makes it easy to see what the current state is (without going to a UI), and also makes it much easier to build tooling around that state, as the API data sync problem disappears.

Looking at DevCycle, it seems you've not taken this approach, is that right? Scanning your docs it seems there's an API to update state, but that fundamentally it's kept in your database, not in code. In my experience this isn't the best dev experience, so as dev experience is your USP, I'm interested in why you think this is a better experience, what benefits it can bring over a "git-ops" style, or what I've missed in your docs.


Feature flags in source control seems to be missing the point.

Separating feature flags and source let’s you decouple your code releases from your feature releases. Requiring a deploy of new to code to enable or disable a feature seems to negate almost all of the benefit of using feature flags to begin with.


They don't necessarily have to rolled out as part of the same release process. You can still decouple them without giving up them being version controlled which to me is also preferable over just toggling things through a gui.

Having a release process for flags also allows you to run integration tests with those flags, canary alerting and automated rollbacks.


Yes this is how I view it. Just because it's in code doesn't mean it's the same codebase, same deployment process, same servers, or anything else. Code is the source of truth and log of how that truth changed over time.


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.


Thanks for the detailed reply, although I feel like I may have miscommunicated the aim here. I'm not really thinking about what is being launched, but how, and where the truth lives.

A CLI is certainly a nice feature, but brings decisions that need to be made: who runs it, where do they run it, when, how do you know what was run, how do you deploy the CLI, and so on. The same can be said for, say, running your test suite – and the solution there is to have CI do it for you. Sure you can run, but the run that matters is the one when you merge your branch and that's done in a controlled environment typically defined in code.

Rolling out features/flags is the same, and I think if the state of all the flags, features, traffic allocations, targeting, and so on, is all defined in code, then all those questions you get with a CLI go away. Who runs it? An automated process. Where do they run it? In a controlled environment, not on a dev machine. How do you know what was run? It's all there in code. How do you deploy the CLI? You don't need to.

> 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

I'm interested as to why you say this has many advantages, because I don't see why a git based workflow couldn't run this. You could for example have DevCycle subscribe to the notifications for the git repo and update its internal state any time new changes are made to the git repo. That would be preferable over a UI or CLI because the whole state is there in a machine readable format ready for tooling to use.


You can use a git-based workflow for feature flags, that's likely how most teams will start using flags in their code with environment variables and infrastructure state. However, most deployment pipelines in the wild are very slow and owned by engineering, limiting the value of doing git-based state for your Feature Flags.

I've seen that disconnecting the deployment of code from releasing of features can be transformative in various ways that fit better with an API-based model for Feature Flags:

- Many flags / remote config changes in production environments are made by non-developer members of a team.

- Coordinating releases across multiple platforms that have different deployment cycles. For example, deploying a new feature to Mobile + Web + APIs simultaneously.

- Enabling / disabling flags in real-time across your stack to respond to incidents.

- Support / Sales teams using Flags to gate features for customers.

- Remote config to populate data for UIs, to act as a CDN for content.

- Rolling out infrastructure changes, being able to roll back changes instantly without another deployment.

(And for context: our Feature Flag decisioning is done locally for our local bucketing server SDKs)


I put this in another comment, but disconnecting of code and feature release can still be achieved while storing feature flags as code. You need to build out a seperate pipeline and release process. With this you can still achieve all the advantages that you listed out.

I think the key difference is if you consider feature flags to be configuration and believe in configuration as code as a best practice.

I think this is the right approach in the long term. People having the ability to modify configuration in production in real time is an outage waiting to happen without having an obvious way to rollback to previously known working state.


We certainly see workflows where defining everything as code can be powerful. As we've been chatting about this internally today, we have ideas of how you could define all your features / audiences / variables as code and only deploy changes using a Terraform interface.

I feel like, ultimately, this overly limits the reach of feature flags within an organization; it makes it more difficult for most engineers who are not comfortable with Terraform to deploy their features; it limits the ability of product / marketing / project managers / QA from; scheduling releases, configuring experiments, testing features, modifying audiences, etc.

Modifying configurations certainly can cause production issues, which is why we have built tools like our variable schemas and strong typings for our variables to limit the value changes to only known values. With our CI / CLI / IDE integrations, we make it known what values variables can be set to, when variables are added and removed, and when variables enabled in production are modified by PRs. This is all in addition to existing permissions / change logs / rollback functionality we are improving on. One of our core responsibilities is to make changing Feature Flag values as safe as possible. We know that flags can quickly become tech debt, so we also preach that feature flags should be as easy to remove from your code as they are to add to your code.

A fully featured feature management platform should be with you from your IDE / CLI, Code Review / CI, Deployment Pipelines / Alerting and Monitoring, and integrated with your Project Management and Product Analytics. It should be visible to your team throughout their workflows what features are enabled across all your environments.


I don't think using source control is incompatible with this. You can persist state in source control, and have a separate deployment pipeline that is triggered only for updates to feature flag files. It is also deployed separately; e.g., to a key-value store.


Prefab has something that you could use in more or less this way. The value of the flag can come from different sources and there is a defined order precedence. The base levels are default yaml files, which would be committed in your project. We think of live values from the server as a "potential override". So if you only wanted things in git you could just not use the UI. Details in https://docs.prefab.cloud/docs/explanations/bootstrapping

I'm spike-ing on some similar/adjacent things right now actually if you want to jam. I won't claim that what exists today is very polished for your usage pattern.


How did you represent the features flags in source control?


Just a config file defining the flag, how it was targeted at users or other entities, how much it was rolled out, etc.


How do you differ from LaunchDarkly?


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.


Hey I'm one of the product folk here at DevCycle.

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.


Aren't non-binary flags even worse from the point of view of deleting them?

There is a very good reason feature flags are binary: they start in one state and end in the other.


This is definitely an interesting challenge you bring up.

I think regardless of the how difficult it is to remove a non-binary flag, the market has moved feature flagging away from just binary and merged with the concepts of remote configuration and experimentation, both of which require more than just ON/OFF states.

For us, we're not trying to shy away from that challenge, so it forces us to come up with interesting solutions to the problem.

A couple ways we're solving for this problem are:

1. Variable Schemas - We just launched a feature that allows for engineers to strictly define the acceptable values of any feature flag they are creating, so that as other team members interact with those flags, there are programmatic controls in place that create guardrails on the input. This also does double-duty in creating strongly typed code, so that usage in code is clear, easy to navigate, use and cleanup when the time comes.

2. Code Cleanup - An example of one of those solutions is our Code Cleanup CLI command. Regardless of what the flag type is (boolean, number, string, JSON) you can provide the prompt with what you would like the end state to be and the AST logic built into the CLI will create a proposed diff for your code wherever a DevCycle flag exists which you can then either edit further or submit directly for a PR.

I 100% agree non-binary flags present a challenge, but we are definitely interested in finding unique ways to solve that problem.


We use growthbook and love it. In what ways do you differ?


Hey, awesome that you use Growthbook. They seem to be doing an amazing job on the data and analytics space tied to A/B testing and feature flagging.

Our perspective differs from Growthbook's in that we don't want to replace your analytics source of truth in any way. Product analytics has come a long way in the last few years with a lot of truly amazing players like Mixpanel, Amplitude, Looker or almost countless others.

Our core focus is developers and the developer experience.

What that means is that we're trying to avoid adding features and functionalities that would be directly competitive to analytics providers, and instead be better at integrating with those tools, so you can manage your flags in DevCycle and do your flag and experiment analysis directly in your team's source of truth.

At the moment what this means for our product roadmap is that we're working on things like a feature rich CLI, Typescript enhancements, automatic code cleanup, etc and we're hoping to continue to head down the road of developer experience as opposed to building non-developer tooling.


> Local bucketing does all of the calculations locally using extremely performant Web Assembly code.

I don't understand; are you bundling an entire WASM environment in the SDK to interpret flags?

> Whether you are developing for the web, back-end servers, or mobile devices, we've got you covered.

Is desktop client support on the roadmap?


Happy to provide more details on this. In most cases, our server SDKs use a common WASM library to make all user bucketing and segmentation decisions locally. We have been impressed with the performance we've achieved with WASM. It allows us to share our most critical non-trivial amount of decision-making code, and it lets us share it between our Edge APIs and Server SDKs. So the same WASM code making decisions locally in our server SDKs is also making decisions at the edge for our APIs powering our client-side SDKs and public APIs.

We have stuck to the Bytecode alliance-supported Wasmtime runtimes that we highly recommend for anyone going down a similar path.

There have been cases with highly parallel environments where we needed to support micro-second level optimizations for our GO SDK, where we ended up building a native version of our bucketing logic. We hope that WASMs' upcoming threading and memory management improvements will make this use case supportable without needing native code. But for our higher-level language SDKs like NodeJS / Python / Ruby / PHP we've generally seen as good or better execution performance from WASM.

What desktop environment are you looking to support? We have customers using our iOS SDK in MacOS (we need to find a better name for our Apple platforms SDK that supports iOS / iPadOS / MacOS / WatchOS / tvOS). Our React SDK works with electron apps, and we have on our roadmap to investigate client SDK support for our .NET SDK.


Congrats on the launch! Will be great if you can shed some light on your initial customer acquisition journey. How did you go about marketing and finding the first few customers?


Hey, thanks so much!

This is an interesting question, given our unique situation, as DevCycle is effectively a startup within a startup.

As I mentioned in the post, we created DevCycle because of a need we saw among our customers at Taplytics. So in terms of finding first customers, our primary goal was to make DevCycle better than Taplytics for this specific use case as quickly as possible. Once we got to a minimum viable product that was sufficiently good, the conversation with relevant customers at Taplytics was easy, because we were able to point to a product that better fit critical use cases for them.

Beyond those customers, because our focus is on Developer Experience we are taking a Developer-Led approach to customer acquisition. So this means trying as best as we can to write and create quality content, sponsoring developer-focused podcasts/twitch streams, etc. It also means meeting developers where they already are, and supporting others that are building amazing communities. So we are trying to be very active participants in communities like OpenFeature.

We for sure have a long way to go, but from a product and engineering perspective, it's nice for the team to be able to feel like they can participate in the customer acquisition journey by just talking about the interesting challenges they are facing day-to-day.


imo you shouldn't need an external service. IaC abstractions can be used to do this more generally


I like the domain name.

But isn't feature flag management market too crowded by now?

Why should DevCycle be allowed to exist?


(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.


Why should I pick you, when there are so many alternatives? I have more candidates than I can try: DevCycle, enrolla, FeatureHub, Featurevisor, Flagsmith, Flipt, Flux, GrowthBook, LaunchDarkly, Prefab, Split, Unleash


100% there are some great options on the market right now and I can't imagine anyone trying all of them.

The reality is that most of the products on that list are tackling the problem in a different way, targeting their own specific niche.

I would only recommend looking at the products that resonate with your needs.

With us for example, if our focus on Developer Experience and fitting into your coding workflow resonates, that's great, you should try us out in comparison to the others that position that way.

But if that doesn't resonate and say Growthbook's focus on analytics and data warehouse connections is more important to you, you should look at them and others like them instead.

We're definitely not trying to be all things for all potential users of feature flags, but we're hoping that what we're offering matters to small teams of developers that care about embedding feature flagging into their development process


How do Launch HNs work exactly? Is any group that was part of any YC batch allowed to do a Launch HN and continue to do so each time they pivot? I don't have an issue with this, I'm just trying to understand why a startup that was in the Winter 2014 batch is doing a Launch HN nearly nine years later. Presumably they pivoted several times, perhaps from something not even remotely related to feature flags?

I know some of the details of how to submit a Launch HN are described here https://news.ycombinator.com/yli.html but doesn't quite answer my questions. Just curious!


They hadn't done one before and each startup gets one. They aren't even the oldest - I think RescueTime (YC W08) has the record: https://news.ycombinator.com/item?id=28683597

We're thinking of relaxing the rules so that a startup that's working on something fundamentally different can do a later Launch HN (perhaps after a year or two have gone by), but that's still undecided.


Thanks for the clarification dang


If I understand correctly, DevCycle is new, but Taplytics (from that YC batch) is the parent. DevCycle doesn't seem to be a decade old.


That is correct!

DevCycle is quite new, we just started working on it in 2022.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: