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?
Could it add insights on which flags are impacting user behavior the most?
The PR review flow is what caught my attention here. Treating feature flag changes like normal code changes should make the whole process feel much more familiar.
This feels nicely aligned with how coding agents actually work. No separate dashboard or account to set things up is a pretty refreshing approach.
I like the idea of keeping feature flags right inside the repo. Having the reason and decision in the same markdown file makes changes much easier to understand later.
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?
I have used separate tools for A/B tests before so keeping the experiment inside the repo feels interesting.
The A/B testing part caught my attention. Can you run simple UI experiments with it as well?
You asked for the critical version. Flags in git means flipping one takes a commit, a review and a deploy, and the reason teams pay for a flag service is the kill switch at 2am without any of that. For agent facing flags it's a fine trade, for a gradual rollout or an incident it isn't. Markdown also won't fix dead flags, since nothing gets reviewed when nothing changes and the flag nobody has touched in four months is still branching in prod.
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 context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.
The simple approach sounds great early on but does the file structure stay manageable as the repo grows?
“Markdown feature flags your coding agent installs for you”
dif.sh launched on Product Hunt on September 5th, 2026 and earned 220 upvotes and 18 comments, earning #1 Product of the Day. 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.
dif.sh was featured in Open Source (68.8k followers), Developer Tools (518.7k followers), Artificial Intelligence (477.7k followers) and GitHub (41.4k followers) on Product Hunt. Together, these topics include over 244.1k products, making this a competitive space to launch in.
Who hunted dif.sh?
dif.sh was hunted by fmerian. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how dif.sh stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
fmerian
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.