{"slug": "statsig", "name": "Statsig", "category": "other", "category_name": "Other software", "description": "", "recommenders": 3, "commenters": 3, "warners": 0, "score": 2.715, "rising": -0.98, "first": "2026-05-26", "latest": "2026-05-27", "why": "large amounts of our product copy and rollouts were driven off of it.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 0, "compare": 0, "warn": 0}, "spark": [0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "large amounts of our product copy and rollouts were driven off of it.", "kind": "", "icon": true, "domain": "statsig.com", "github_repo": null, "official_url": "https://statsig.com", "pricing": "", "aliases": ["Statsig"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 772741472, "item_id": 48296342, "url": "https://news.ycombinator.com/item?id=48296342", "by": "chambers", "date": "2026-05-27", "version": null, "stance": "recommend", "quote": "That's how Statsig built their system and, in part, why they could sell for a billion.", "excerpt": "Yes, feature flags are conflated with dynamic configs (or \"remote configs\"). The difference is crucial, hence why people are talking past each other. Feature flags are gates for whether a piece of code runs; basically, an if-condition. Dynamic configs are a mechanism for changing runtime values without redeploying[1]. For example: # Feature flag \u2014 variant gate for rollout flag = SOME_CONSTANT_DEFINED_IN_MY_REPO # rem", "context": "", "use_case": "", "switched_from": "", "story": "Cloudflare Flagship"}, {"id": 772621984, "item_id": 48288874, "url": "https://news.ycombinator.com/item?id=48288874", "by": "elamje", "date": "2026-05-26", "version": null, "stance": "recommend", "quote": "large amounts of our product copy and rollouts were driven off of it.", "excerpt": "I\u2019m always excited when Cloudflare starts offering things that I had to use other providers for because I know it will be solid. We used Statsig at Function. It started out as 2 of us using it on one product and within 12 months, large amounts of our product copy and rollouts were driven off of it. Statsig has client side evals so you can write rules and rollouts based on internal concepts without Statsig\u2019s servers p", "context": "", "use_case": "feature flags and rollouts", "switched_from": "", "story": "Cloudflare Flagship"}, {"id": 772620241, "item_id": 48288765, "url": "https://news.ycombinator.com/item?id=48288765", "by": "btown", "date": "2026-05-26", "version": null, "stance": "recommend", "quote": "Statsig has an approach here that I quite like", "excerpt": "Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context). And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn\u2019t see certain features on that specific inventory at certain times. When you can write your own logic, and just run this ", "context": "", "use_case": "", "switched_from": "", "story": "Cloudflare Flagship"}]}], "caveats": [], "who": [], "tags": [], "use_cases": ["feature flags and rollouts"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=48287468", "title": "Cloudflare Flagship", "mentions": 3}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {}, "2026-03": {}, "2026-04": {}, "2026-05": {"recommend": 3}, "2026-06": {}, "2026-07": {}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 772741472, "item_id": 48296342, "url": "https://news.ycombinator.com/item?id=48296342", "by": "chambers", "date": "2026-05-27", "version": null, "stance": "recommend", "quote": "That's how Statsig built their system and, in part, why they could sell for a billion.", "excerpt": "Yes, feature flags are conflated with dynamic configs (or \"remote configs\"). The difference is crucial, hence why people are talking past each other. Feature flags are gates for whether a piece of code runs; basically, an if-condition. Dynamic configs are a mechanism for changing runtime values without redeploying[1]. For example: # Feature flag \u2014 variant gate for rollout flag = SOME_CONSTANT_DEFINED_IN_MY_REPO # rem", "context": "", "use_case": "", "switched_from": "", "story": "Cloudflare Flagship"}, {"id": 772621984, "item_id": 48288874, "url": "https://news.ycombinator.com/item?id=48288874", "by": "elamje", "date": "2026-05-26", "version": null, "stance": "recommend", "quote": "large amounts of our product copy and rollouts were driven off of it.", "excerpt": "I\u2019m always excited when Cloudflare starts offering things that I had to use other providers for because I know it will be solid. We used Statsig at Function. It started out as 2 of us using it on one product and within 12 months, large amounts of our product copy and rollouts were driven off of it. Statsig has client side evals so you can write rules and rollouts based on internal concepts without Statsig\u2019s servers p", "context": "", "use_case": "feature flags and rollouts", "switched_from": "", "story": "Cloudflare Flagship"}, {"id": 772620241, "item_id": 48288765, "url": "https://news.ycombinator.com/item?id=48288765", "by": "btown", "date": "2026-05-26", "version": null, "stance": "recommend", "quote": "Statsig has an approach here that I quite like", "excerpt": "Never underestimate the power of a zero-network-hop abstraction over f(feature_name, context). And context can be extremely tailored to your niche: specific inventory, from a specific supplier, for a specific user of a specific B2B client of a specific business model subtype, who should or shouldn\u2019t see certain features on that specific inventory at certain times. When you can write your own logic, and just run this ", "context": "", "use_case": "", "switched_from": "", "story": "Cloudflare Flagship"}]}