Show HN: FFlags – Feature flags as code, served from the edge (fflags.com)

42 points by tushr ↗ HN
Hi HN,

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.

14 comments

[ 2.8 ms ] story [ 37.5 ms ] thread
Great product! Actually a big point that I've seen in enterprises.
Thank-you! Do let me know how was your experience if you to use it.
Love that it is build on open standards, i hate vendor lockins. Will pitch this at my org with a POC :)
This product is probably not intended for me but at this stage I'm not even sure I know what a feature flag is any more.

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?

You are right, feature flags are just toggles but the devil is in the details. When the product scales you would want to test things internally or with a close group of people on prod before you make it public (beta releases). Sometimes you would want to release features at a specific time (Apple, Figma product launches). Sometimes you would want to test if A is working better than B (A/B testing typically in eCommerce sites). Sometimes features are location-specific (Different content for different countries, netflix does this). Let's consider a scenario: You have a team of 10 engineers working on 5 different features. They merge their feature branches to a main branch which gets deployed at the end of the release cycle. Now, if one of those features isn't working as expected, the engineers will have to roll back to the last deployment which won't have any of the 5 features. With feature flags, this could be avoided by developing all features behind a feature flag.
Love the simple landing page! How big is the free tier? The pricing slider seems to show that you pay $39 for anything more than 0 requests.
Aah! That's a miss from my end. I had it on my previous landing page. It is 100k requests a month. But, I am not adding any cap right now. I monitor the system all the time so if it goes above the free tier limit significantly I will notify.
Cool product and great landing page. This is quite off topic: how did you make the code animation in the Feature Flag as Code section? I reminded me of prezi.com (with their slide animations). Would love to know!
Why does this need to be a dependency? In my view feature flags are core enough not to be outsourced to a third party. Although, there are companies using libraries for "isEven" so there might be a market for it.
That's a fair point! Basic feature flags are just toggles, true and false. But they quickly become complex as you onboard new customers and scale. You need percentage rollouts to make sure things are working before everyone starts using the features. It only makes sense for engineers to spend time building actual features and testing them in production rather than spending bandwidth on building a feature flag management tool or managing the service for the same. This is a typical build vs buy debate. :D
I thought it's satire. Like "/dev/null as a service".
One of the key aspects of feature flag systems is enabling A/B analysis, measuring the impact of features on metrics like click-through rate, session duration, and revenue. This doesn’t seem to be mentioned in the highlights. Is the product targeting these kinds of insights?
Great product glad its built on open standards!