Blog
Notes on feature flags, A/B testing, and keeping experiments in the repo. Concrete, and mostly about files.
- Self-hosted feature flags without a server to run Self-hosted feature flags usually mean a database and an API server. dif skips both: flags are Markdown files in your repo, read locally with no service to run.
- A/B test statistical significance, explained A/B test statistical significance means the gap between variants is unlikely to be random noise, not that it's big or worth shipping. Here's what it says.
- Feature flag testing: verify a flag without redeploying Feature flag testing without a redeploy: dif qa traces a user's assignment and mints a preview link that forces a variant and fires no exposure event.
- Deploy vs release: the difference feature flags make A deploy puts new code on your servers. A release is the moment a user can see it. Feature flags split the two, so shipping stops meaning everyone sees it.
- Dark launches: ship it before you turn it on A dark launch ships code to production with the feature hidden, so you can test real infrastructure load before anyone sees it. Here's how to do it with a flag.
- Experiment decisions as code: hypothesis to conclusion in a PR A tutorial that walks one A/B test from a Markdown hypothesis through dif validate, dif build, dif qa and dif conclude, with real output from dif 0.6.3.
- Checking an experiment exclusion graph at build time, in Rust How dif build parses Markdown experiment files, proves which pairs can never share a user, refuses to compile the rest with E007, and emits a TypeScript client.
- Release trains: why feature flags let you skip them A release train ships on a fixed schedule, so code that misses the cutoff waits for the next one. Feature flags let you merge daily and skip that wait.
- Feature flags in Node.js: a practical guide Feature flags in Node.js: install the SDK, read a flag with one function call, and gate a route or job. Deterministic assignment, no database, ~5 kB.
- Minimum detectable effect: how big a lift you can see Minimum detectable effect is the smallest lift your A/B test can reliably see. Here's the formula, real sample sizes, and where to write the number down.
- Open source feature flags: what to look for Open source feature flags range from a self-hosted platform to files in your repo. Here's what to check before you pick one, and what each option costs you.
- Config as code: where feature flags fit in Config as code means configuration ships through the same PR as application code. Here is where feature flags fit, and where they outgrow a config file.
- The PostHog alternative for teams that want flags in git The open-source PostHog alternative: feature flags as Markdown files in your repo, not PostHog's dashboard. Free CLI, 5 kB SDK, no analytics stack to run.
- Staged rollouts: shipping to 1% before 100% A staged rollout ships a change to 1% of users, then widens it in steps as a metric holds, until it reaches 100%. Here's how to pick the rollout steps.
- Guardrail metrics: the numbers that stop a test A guardrail metric is the number you watch so a win on your primary metric doesn't hide a quieter loss. How to pick one, and when to stop a test.
- Canary releases and dark launches, explained A canary release ships a change to a small slice of users, then widens it as metrics hold. Here's how it differs from a dark launch, and when to use each.
- How to remove a stale feature flag before it rots How to remove feature flags: collapse the dead code path in one pull request, then run dif conclude to archive the flag file and record why it existed.
- Running concurrent A/B tests without mixing results Concurrent A/B tests on the same page can contaminate each other. Exclusion groups guarantee each user sees one test's variant, so results stay attributable.
- The Statsig alternative for teams that want flags in git The open-source Statsig alternative: feature flags and experiments as Markdown files in your repo, reviewed in a pull request, no console or account needed.
- Feature flags in TypeScript with a generated client dif compiles your feature flags into a generated TypeScript client, and dif validate checks every dif("flag-id") call site against real flag ids before it ships.
- Feature flag kill switches: what a merge can and cannot do A feature flag kill switch turns off a broken code path without rolling back the release. Here's what a merge-based kill switch can do, and where it can't beat a dashboard.
- How to write an A/B test hypothesis worth reading A good A/B test hypothesis names the change, the metric, and the reason in one sentence, and survives contact with real data. Format, examples, and mistakes to avoid.
- Feature flag best practices that survive code review Feature flag best practices that survive code review: name flags for the change they make, enforce an owner field, and validate them in CI before merge.
- Feature flags vs feature toggles: the same thing Feature flags vs feature toggles: the same thing. One runtime switch around a code path, two names. Where each came from and which one to standardize on.
- Feature flag vs A/B test: what is actually different A feature flag and an A/B test use the same runtime switch. The difference is intent: a flag ramps to 100%, an A/B test holds a split until a metric answers.
- Deterministic bucketing: how a user gets a variant Deterministic bucketing assigns a variant by hashing the user id with the flag's salt, mod 10,000. No database, no network call, and no flicker between loads.
- Feature flags in SvelteKit with server-load assignment Feature flags in SvelteKit: assign every flag in +layout.server.ts with difLoad, hydrate the same decision on the client, and never flash the control variant.
- Experimentation with Claude Code and Cursor Experimentation with Claude Code and Cursor: your agent writes both variants and the dif experiment file, dif runs the split, and the result lands in git.
- Feature flags in Next.js with the App Router Feature flags in Next.js: resolve the variant on the server with assign(), gate client components with a provider, and stop the flicker after hydration.
- What is a holdout experiment? When to run one A holdout experiment keeps a slice of users on the old experience after a change ships, so you can measure the long-run effect a two-week A/B test misses.
- Agent-driven experiments with dif: your coding agent writes both variants Agent-driven experiments: your coding agent writes variant A and variant B behind a dif flag, dif runs the test, results feed back on the next session.
- AGENTS.md for feature flags: the block dif writes for your coding agent A coding-agent-ready AGENTS.md feature-flag block tells the agent where flags live, the schema, the gating pattern, and how to validate. Real block inside.
- The open-source Flagsmith alternative: dif keeps flags in your repo, no server The open-source Flagsmith alternative: feature flags as Markdown files in your repo, no Django server or Postgres to run. Free CLI, 5 kB SDK, MIT licensed.
- LaunchDarkly pricing alternative: dif Cloud at a flat $50/mo, not usage meters LaunchDarkly pricing alternative in 2026: dif Cloud Pro is a flat $50/mo for 1 million events with unlimited seats. The CLI and SDK are MIT and free forever.
- The Unleash alternative: dif puts feature flags in your repo An Unleash alternative that skips the Node.js and Postgres server. dif keeps feature flags in your repo as Markdown files, reviewed in a pull request.
- Validate feature flags in CI with dif validate Validate feature flags in CI with dif validate. It catches weight sums that miss 100, orphan call sites, and two experiments colliding on one surface.
- Let an AI agent create a feature flag and validate it with dif Let an AI agent create a feature flag: it writes the Markdown file, gates the code, and runs dif validate on its own work, so a broken flag fails the PR.
- The best feature flag tools in 2026, compared by the dif team The best feature flag tools in 2026, compared: dif, LaunchDarkly, Optimizely, Split, GrowthBook, Flagsmith, Unleash, and Statsig, with who each is for.
- What is dif context.json? The flag state your agent reads context.json is the file dif build emits so a coding agent reads your live feature-flag state on session start. What is inside it, and how the agent uses it.
- The open-source Optimizely alternative: dif puts experiments in your repo dif is the open-source, git-native Optimizely alternative: experiments and feature flags as Markdown files in your repo, reviewed in PRs, with a 5 kB SDK.
- The open-source Split alternative: dif puts flags in your repo dif is the open-source, git-native Split alternative (now Harness FME): feature flags and experiments as Markdown files in your repo, free CLI, 5 kB SDK.
- Why flag dashboards fail AI coding agents, and what dif does instead Why dashboards fail AI coding agents: an agent reads your repo, not a UI behind a login, so it cannot see flags in a dashboard and breaks the ones it cannot read.
- Feature flags for AI agents: dif flags your coding agent can read Feature flags for AI agents means flags a coding agent can read and write, because they are files in the repo. Why dashboards fail agents, and the fix.
- dif vs GrowthBook: flags in your repo, or in an app dif vs GrowthBook: both are open source. dif keeps flags and experiments in your repo as files; GrowthBook runs them in a warehouse-native app. How to choose.
- Feature flags in React: a practical guide with dif Feature flags in React: install the SDK, wrap your app in a provider, and gate a component with the useDif hook. Deterministic assignment, no flicker, ~5 kB.
- A/B testing for developers: experiments in code with dif A/B testing for developers means running experiments in code, not a dashboard: split traffic deterministically, measure one metric, and conclude with a decision.
- The open-source LaunchDarkly alternative: dif puts feature flags in your repo The open-source LaunchDarkly alternative: feature flags and A/B tests as Markdown files in your repo. MIT licensed, flat pricing, one command to install.
- Feature flags in git with dif: the case for flags as code Feature flags in git means flags live as code in your repo, reviewed in a pull request and versioned like anything else. Here is how the workflow works and its tradeoff.
- What are feature flags? A developer's guide from dif A feature flag is a runtime switch that turns a feature on or off without a deploy. Here is how feature flags work, the main types, and how to keep them from rotting.