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
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.
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.
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.
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.
I completely agree with this point that it is extremely challenging to make money on mobile. There are options, however, in the market if you are looking for a mobile A/B testing platform that understands this.
To be completely open and honest, I am a co-founder of Taplytics. I just wanted to hop in here and point out that we have a Startup Plan that gives independent developers and mobile teams completely free use of our platform.
Thanks for the comment. We agree that keeping your web presence in sync with your mobile product is critical. We have built Taplytics out as a big API engine with the goal of managing multiple platforms, iOS is just where we're starting.
Obviously you know your customers better than I do, but I bet you could keep the free plan, 2x-3x your middle plan, and 5x your upper plan and still service the same number of customers.
The delta from $20 to $50 isn't going to break anyones bank, but I suspect the change in unit economics mean big things for your business/LTV.
DevCycle is quite new, we just started working on it in 2022.