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?
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.
Report
The simple approach sounds great early on but does the file structure stay manageable as the repo grows?
Report
the context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.
Report
I like the RR based approach here because every flag change gets context. Could dif.sh also show a simple history of why a flag changed over time?
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
Oboe
@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?
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.
The simple approach sounds great early on but does the file structure stay manageable as the repo grows?
the context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.
I like the RR based approach here because every flag change gets context. Could dif.sh also show a simple history of why a flag changed over time?