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

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.

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.

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)

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.