Open source feature flags as markdown files in your repo: the flag, the reason, the decision in one file, reviewed in a PR. One command, no account, so your coding agent can finish the install. A/B tests wait in the same files until you have traffic.
A while back I asked Claude Code to add feature flags to a project. It got to the part where most flag tools want you to create an account, grab an API key, etc., and basically gave up and wrote `process.env.SHOW_NEW_CHECKOUT` instead.
That was the thing that got us thinking about Dif. Dif keeps flags in your repo as markdown files. They get reviewed in PRs like everything else. You can install it with one command, there's no signup or API key required, and coding agents can actually use it without getting stuck halfway through.
`dif init` also adds some instructions to `agents.md`, and we generate a `context.json` on each build so the agent has a better idea of what flags exist, what's been removed, and what's already been tried. A/B tests live in the same setup too, even if you're not ready to run them yet.
The self-hosted version is free. The cloud piece is for getting a view across projects and having Dif propose changes, but those still come back through PRs. Git stays the source of truth.
Would genuinely love the critical version of the feedback here: would you use this? If not, what would stop you? And what are you using today that we'd need to be better than?
@fmerian Yeah, the timing is pretty wild. It also feels like a good reminder that feature flags are important enough infrastructure that they shouldn’t disappear when a vendor does.
That’s a big part of why we wanted Git to stay source of truth and the self-hosted version to be genuinely useful on its own.
And yes, OSS ftw 🙌
Report
I like the idea of treating featuree flags as part of the codebase. How easy is it to explain an old flag when someone joins the project later?
@jordantaylor58 great question! Yes, it's easy. Every flag and experiment is stored as a single .md file. Concluded experiments or inactive flags store context and product decision. During setup you define product surface areas which function as your running logs of what each screen has taught you.
@niyeti_shah When you initialize dif, it installs skills for Claude (and others) that help with authoring feature flags, generating surfaces, and concluding experiments!
The A/B testing part caught my attention. Can you run simple UI experiments with it as well?
Report
@sansa_grey Yeah, that’s a good use case. Simple UI variations like changing a button layout or onboarding flow should be pretty straightforward to test and compare.
@sansa_grey yes! you can run simple and complex UI experiments with dif. When you are ready you can use dif cloud. It reads your repo and turns every .md experiment file into a live view (exposures, lift, confidence intervals and a ready to conclude flag) It gives your team a live read of what is working.
Report
Could it add insights on which flags are impacting user behavior the most?
@darly_selby Yeah, you just need to turn on events (in dif/config.yaml). The easiest way is with dif cloud, but it also works with any other analytics platform. Then any time a flag or experiment is concluded the results are used as context for future experiments!
Report
the context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.
@ashley_james This! Having built dif coming from years of product growth work, we know that learning management is one of the hardest things for growing teams. In the short term, the agent stops re-proposing what has already been tested, in the long run synthesized learnings per surface area and context files should compound. If you try it and it doesn't please tell me.
dif.sh
Hey Product Hunt. David here, one of the makers.
A while back I asked Claude Code to add feature flags to a project. It got to the part where most flag tools want you to create an account, grab an API key, etc., and basically gave up and wrote `process.env.SHOW_NEW_CHECKOUT` instead.
That was the thing that got us thinking about Dif. Dif keeps flags in your repo as markdown files. They get reviewed in PRs like everything else. You can install it with one command, there's no signup or API key required, and coding agents can actually use it without getting stuck halfway through.
`dif init` also adds some instructions to `agents.md`, and we generate a `context.json` on each build so the agent has a better idea of what flags exist, what's been removed, and what's already been tried. A/B tests live in the same setup too, even if you're not ready to run them yet.
The self-hosted version is free. The cloud piece is for getting a view across projects and having Dif propose changes, but those still come back through PRs. Git stays the source of truth.
Would genuinely love the critical version of the feedback here: would you use this? If not, what would stop you? And what are you using today that we'd need to be better than?
We'll be around all day.
Kilo Code
@Flipt Cloud, @Reflag and @Hypertune winding down, it feels like the right time for @dif.sh to launch. and it's open-source! oss ftw
dif.sh
@fmerian Yeah, the timing is pretty wild. It also feels like a good reminder that feature flags are important enough infrastructure that they shouldn’t disappear when a vendor does.
That’s a big part of why we wanted Git to stay source of truth and the self-hosted version to be genuinely useful on its own.
And yes, OSS ftw 🙌
I like the idea of treating featuree flags as part of the codebase. How easy is it to explain an old flag when someone joins the project later?
dif.sh
@jordantaylor58 great question! Yes, it's easy. Every flag and experiment is stored as a single .md file. Concluded experiments or inactive flags store context and product decision. During setup you define product surface areas which function as your running logs of what each screen has taught you.
Curious how this works with Claude code
dif.sh
@niyeti_shah When you initialize dif, it installs skills for Claude (and others) that help with authoring feature flags, generating surfaces, and concluding experiments!
Buffup.AI
The A/B testing part caught my attention. Can you run simple UI experiments with it as well?
@sansa_grey Yeah, that’s a good use case. Simple UI variations like changing a button layout or onboarding flow should be pretty straightforward to test and compare.
dif.sh
@sansa_grey yes! you can run simple and complex UI experiments with dif. When you are ready you can use dif cloud. It reads your repo and turns every .md experiment file into a live view (exposures, lift, confidence intervals and a ready to conclude flag) It gives your team a live read of what is working.
Could it add insights on which flags are impacting user behavior the most?
dif.sh
@darly_selby Yeah, you just need to turn on events (in dif/config.yaml). The easiest way is with dif cloud, but it also works with any other analytics platform. Then any time a flag or experiment is concluded the results are used as context for future experiments!
the context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.
dif.sh
@ashley_james This! Having built dif coming from years of product growth work, we know that learning management is one of the hardest things for growing teams. In the short term, the agent stops re-proposing what has already been tested, in the long run synthesized learnings per surface area and context files should compound. If you try it and it doesn't please tell me.