I'm the creator of FFlags. I built this because I wanted a feature flagging system that gave me the performance and reliability of an enterprise-scale solution without the months of dev time or the vendor lock-in.
The core ideas are:
1. Feature Flags as Code: You define your flag logic in TypeScript. This lets you write complex rules, which felt more natural as a developer myself than using a complex UI for logic.
2. Open Standard: The platform is built on the OpenFeature standard (specifically the Remote Evaluation Protocol). The goal is to avoid vendor lock-in and the usual enterprise slop. You're not tied to my platform if you want to move.
3. Performance: It uses an edge network to serve the flags, which keeps the wall-time latency low (sub-25ms) for globally distributed applications.
I was trying to avoid the heavy cost and complexity of existing enterprise tools while still getting better performance than a simple self-hosted solution.
There's a generous free tier ($39 per million requests after that, with no flag/user limits). I'm looking for feedback on the developer experience, the "flags-as-code" approach, and any technical questions you might have.
Thanks for taking a look.
I thought feature flags were just toggles so you could turn features on and off. I wouldn't know how to implement those as anything other than code. Or why you would need an external service.
What problem is this solving?
- distributing flags to multiple services
- broadcasting updates
- caching rules
- audit logs
- product, not eng, will start managing the flags at some point and needs easy access
- custom logic for gradual rollouts, A/B testing
- custom attributes support (used in evaluation)
- managing multi-variant flags
- supporting multiple platforms (backend, frontend, native apps, services, jobs) and evaluation strategies (eager server-side evaluation vs shipping a client-side engine)
There are quite a few open-source options like Growthbook, Flagsmith, go-feature-flag, and Unleash that you can check out for comparison.
How to tell you have a broken engineering culture.
You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.
If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.
That's the typical pattern and why most tools focus on non-technical UIs. FFlags targets a different niche. Teams where developers want to maintain control over flag logic.
The main appeal of feature flags is simplicity and being a low-hanging way to apply per-customer/user configuration, few platforms allow true a/b testing (amplitude comes to mind but I'm sure there are more).
I don't like feature flags for config. Just build a config system into the product UI - a settings page basically! That might have some bits you configure as the site owner, and some that are self-service.
If you have any kind of back-end infrastructure, it'd seem trivial to implement this yourself. Doing it yourself also allows you to make the feature flags more controlled, e.g. by some flag associated with the current user such as opting into experimental features.
For efficiency, I'd also want to batch a bunch of such flags together, so e.g. when a use logs in they get a list of enabled features that gets cached locally, rather than having to query each and every one via REST.
So I'd echo the question, what problem is this solving?
I am probably not directly an intended user but I sure would be glad to understand what this is (as an amateur dev)