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.
The simple approach sounds great early on but does the file structure stay manageable as the repo grows?
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
@hamza_afzal_butt right now it's the default git conflict behavior. We have found with the .md files that non-technical folks are able to handle those conflicts easily though.
I really like the idea of keeping the flag and the reasoning behind it in the same file. That kind of context usually disappears after a few weeks.
dif.sh
@thomas_bennett Agreed. A lot of flag/experiment tools handle the analysis, but usually they don't keep the actual story of what works, what has been tried, etc.
The idea of treating featuree flags as part of the codebase Is unique
dif.sh
@tolulope_orija TY! ... and with it you unlock a cleaner workflow for teams, better learning management, easier self-hosting, and increasingly important, it allows coding agents to seamlessly interact with it.
dif.sh
To everybody that made our product hunt launch a success! We are proud to have been voted "Product of the day"! We appreciate the enthusiasm and excitement around dif.sh. As always, please continue to share your feedback. We have so many more ideas in the pipeline and can't wait to show you!
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.
dif.sh
@asadmalik901 Thanks for the input. Yeah there are definitely trade offs. We've found it's worth the improved every day performance (no api calls / extra hops) in not having the kill switch but it depends on the organization.
For dead flags, I actually think dif helps with this tremendously. The cli helps to find everything running and used with an agent it can find these pretty quickly.