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