SODAX SDKDigital asset flows you can build and deploy with AI.
Promoted
Launched this week
Open source feature flags. Every flag is a markdown file that lives with the code it controls: what it does, why it exists, and what you decided, reviewed in a PR like any other change. Your coding agent installs Dif in one command, no account, and reads the context file so it knows what's live and what was already tried. A/B tests wait in the same files until you have traffic. Send events to your own analytics, or let Dif Cloud read the results and write the decision into the file.
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.
Mastra
@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?
the context.json part is interesting. i wonder how useful the agent actually becomes once it has access to all those previous learnings.