Hi HN, Cobi here, Co-Founder of DevCycle (<a href="https://devcycle.com" rel="nofollow noreferrer">https://devcycle.com</a>). DevCycle is a feature flag platform focused on developer experience, speed of delivery and long-term maintainability.<p>To give the platform a shot, anyone can sign up and use DevCycle for free here: <a href="https://devcycle.com" rel="nofollow noreferrer">https://devcycle.com</a><p>Here’s a general platform demo video if you’re interested: <a href="https://www.youtube.com/watch?v=bZD-pyKGwR4">https://www.youtube.com/watch?v=bZD-pyKGwR4</a><p>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.<p>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.<p>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.<p>Given this experience, we developed DevCycle with a few core differences in how we solve these problems.<p>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.<p>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).<p>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.<p>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.
Aren't non-binary flags even worse from the point of view of deleting them?<p>There is a very good reason feature flags are binary: they start in one state and end in the other.
> Local bucketing does all of the calculations locally using extremely performant Web Assembly code.<p>I don't understand; are you bundling an entire WASM environment in the SDK to interpret flags?<p>> Whether you are developing for the web, back-end servers, or mobile devices, we've got you covered.<p>Is desktop client support on the roadmap?
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?
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?<p>I know some of the details of how to submit a Launch HN are described here <a href="https://news.ycombinator.com/yli.html">https://news.ycombinator.com/yli.html</a> but doesn't quite answer my questions. Just curious!