Change settings without a deploy or an app store review
A rate limit, a timeout, the copy on the paywall, which model your AI feature calls. They sit in a constant somewhere — so changing one costs a release, and on mobile a release plus a review queue.
The config file problem
Most teams start with environment variables, graduate to a config file per environment, and end up with a small distributed systems problem nobody signed up for.
Constants and config files
- The values live in three places
- Changing one in production means a deploy, an SSH session, or a Terraform run and a restart
- Nobody can tell you what the value was last Tuesday
- These values change more often than the code does
Config on a variant
- One place, changed from a browser
- Targeted per environment, segment, percentage or customer
- Approval before a production change applies
- An audit record of who changed which value and when
A limit tuned during an incident. A timeout raised because a third party got slower. A paywall message rewritten because it read badly. All one-line changes gated behind a full release cycle.
One object
Variant key plus payload
type SearchTuning = {
pageSize: number;
fuzziness: number;
reranker: string;
};
const evaluation = featureflow.evaluate('search-tuning');
evaluation.value(); // 'aggressive' — the variant key
const tuning = evaluation.jsonValue<SearchTuning>();
const results = await search(query, {
pageSize: tuning?.pageSize ?? 20,
fuzziness: tuning?.fuzziness ?? 0.2,
reranker: tuning?.reranker ?? 'default',
});Config that is targeted, not global
Because the payload rides on the variant, everything you can already do with targeting applies to configuration.
Per environment
Staging points at the sandbox endpoint and a generous timeout; production does not.
Per segment
Enterprise accounts get higher limits, defined once as a reusable segment rather than a hard-coded list of IDs.
Per rollout percentage
Tune a parameter for 5% of users, watch what happens, then widen the band.
Per customer, temporarily
Raise one account's limit while you investigate — instead of a hotfix that ships a special case to production.
Config changes are flag changes, so they inherit approvals and the audit trail.
Delivery
Why the client never sees your rules
Rules stay behind the API
Browsers and devices get answers, not logic.
Cached at the edge
The payload is identical for everyone in the same targeting position, so it is served through a CDN and does not hit the origin on every evaluation.
Two deliberate exceptions
featureflow.date and featureflow.hourofday resolve on the client clock — otherwise every response would be unique to the second and nothing could be cached.
Mobile
Old versions of your app stay in the wild for a long time
Frequently asked questions
How is remote config different from a feature flag?
A flag answers a yes/no or which-variant question. Remote config carries a value — a limit, a URL, a copy string, a settings object. In Featureflow they are the same object: every variant can carry a JSON payload alongside its key.
How large can a config payload be?
Up to 32KB per variant, serialized. Comfortably enough for structured settings, feature parameters, copy or a small ruleset — and small enough to keep evaluation fast and payloads cheap to cache at the edge.
How do I read the config value in code?
Call jsonValue() on the evaluation result. value() gives you the variant key as a string; jsonValue() gives you the parsed JSON payload, typed if you supply a type parameter. It returns undefined when the resolved variant has no payload, so a missing value is something you handle rather than a crash.
Does this work for mobile apps waiting on app store review?
That is one of the strongest cases for it. Anything you move from a compiled constant into remote config becomes changeable without submitting a build. React Native is supported by the client SDKs, and config is served through a CDN and cached at the edge.
Are my targeting rules visible to the client?
No. Client-side SDKs receive pre-evaluated results rather than your rule set. Two conditions are the deliberate exception — featureflow.date and featureflow.hourofday are evaluated on the client against its own clock, which keeps the rest of the response identical for everyone and therefore cacheable.
Do config changes get the same approvals and audit trail?
Yes — config changes are flag changes, so they inherit approval before a production change applies and an audit record of who changed which value and when. That is more governance than most teams have over the config file it replaces.
Move your first constant out of the build
Free forever tier, every SDK included, no credit card. Pick the value you have most often wished you could change from a browser.
What else Featureflow solves
Kill switch
Turn a bad feature off without shipping a hotfix
Progressive rollout
Reach 1% of users before you reach all of them
Release pipelines
The rollout process runs itself instead of being remembered
Approvals & audit
Answer 'who changed production?' without an enterprise contract
Mobile releases
Update the app your users already installed
A/B testing
Split traffic and record what each variant actually did