Type-safe feature flags

GraphQL schema, no limits on your logic, build-time mode for Jamstack apps and Git version control.

Type-safety

Hypertune

Auto-generated, type-safe flags, based on your GraphQL schema, that give you compiler errors for typos and return the right types.
Code completion in your IDE.
Find all references of a flag using your IDE, like any other function.
Type-safe flag clean up. Just remove it from your GraphQL query, re-run code generation and fix all the type errors in your IDE.
Type-safe enum flags that return enums you can exhaustively switch on.
Type-safe object and list flags based on your GraphQL configuration schema. Easy to change the types later.
Pass context arguments like userId, email, etc, in a type-safe way with compiler errors if you miss or misspell one, and code completion in your IDE.
Type-safe UI that prevents invalid logic, invalid context arguments and missing enum cases.

LaunchDarkly and others

Flags could be in kebab-case or camelCase. Get runtime errors if you guess wrong or have a typo. Manual, unsafe type casts for non-Boolean flags like Ints and Strings.
No code completion so you have to leave your IDE, find the flag in the UI, copy its name, paste it in your code as a raw string, then figure out if you need to convert it from kebab-case to camelCase.
To find flag references, first figure out if it's in kebab-case or camelCase, then manually search for it. Get incomplete and cluttered results.
To clean up a flag, first figure out if it's in kebab-case or camelCase, then manually search for it, then carefully remove each reference. Get runtime errors if you miss one.
Enum flags not really supported. They return raw strings so you can't exhaustively switch across all possible cases. Silently break your code if you miss or misspell a case.
Object and list flags not really supported. They return raw JSON so you have to manually write (and maintain) brittle code to parse it. High risk of runtime errors. Difficult to change the type later.
Context arguments not passed in a type-safe way. Silently break your flags if you miss or misspell one or it has the wrong type. High risk of errors with enum and object arguments like planType, environment, user, etc. No code completion in your IDE.
No type-safety in the UI. Silently break your flag logic if you use invalid arguments or miss enum cases. Break your app in production if you edit raw JSON flags incorrectly.

Powerful configuration language

Hypertune

A full programming language under the hood. No limits on your logic. Express anything you can express in code. Not locked into a limited DSL.
Embed logic within flag values, e.g. within object fields or list items. Or keep logic at the top-level to return whole different objects or lists.

LaunchDarkly and others

Locked into basic disjunctive normal form so can't express flag logic like "if (A or B or C) and D". Forced to rewrite as "if (A and D) or (B and D) or (C and D)" with duplicated logic that's error-prone and harder to input, read and maintain.
Can't embed logic within flag values, e.g. can't embed logic in JSON fields or list items.

Build-time configuration

Hypertune

Avoid UI flickers. Embed a snapshot of your flag logic in your app bundle for instant SDK initialization with no network latency.
Maintain a good user experience even if the SDK fails to initialize from the server.
Use for critical configuration like permissions, pricing plans, etc.

LaunchDarkly and others

Get UI flickers when the SDK initializes. Not built for Jamstack.
Bad user experience when the SDK fails to initialize.
Not suitable for critical configuration.

Git version control

Hypertune

All your flags and configuration are versioned together with a single Git history. Quickly pinpoint bad commits after incidents and instantly roll back to known good states.
Group changes to multiple, related flags in a single, atomic commit to prevent bad combinations and easily roll them back in one step.
Integrate with GitOps workflows.

LaunchDarkly and others

Flags are versioned separately. Difficult to figure out what combination of flag changes caused an incident then roll back to a good state.
Can't make changes to multiple, related flags in a single, atomic commit. Risk breaking your product with bad combinations of flag values as you make a sequence of flag changes. No single commit in your history that you can easily understand later and roll back.
No Git integration.

Granular analytics and permissions

Hypertune

See how often different branches of your logic are called, e.g. how many users pass each flag targeting rule.
Set granular permissions on your logic, e.g. to let customer success edit a list of user IDs but not the surrounding logic.

LaunchDarkly and others

No granular analytics of how many users pass each flag targeting rule. Only aggregated analytics.
Can't set granular permissions, e.g. to allow customer success to add new users to a flag but not change the other targeting rules.

Flag-specific arguments

Hypertune

Define flag-specific arguments, like projectId or promoCode, that are only relevant to a specific flag or group of flags.
Flag arguments like promoCode can change on different evaluations in the same user session. So you can have flags that depend on the session state like user input, selected options, the current view, etc.

LaunchDarkly and others

Can't have flag-specific arguments. Context arguments can only be passed at the top-level.
Can't have flag arguments that change on different evaluations in the same session. All context arguments must be passed at SDK initialization and stay the same for the whole session. So you can't have flags that depend on the session state.

Flag groups and namespacing

Hypertune

Group and namespace flags in object hierarchies in your schema.
Manage the possible combinations of flag values by grouping them with shared targeting logic.

LaunchDarkly and others

No namespacing so flags have long, complex names that are hard to find, read, remember and communicate.
Can't prevent bad combinations of flags like disabling topNavbar and sideNavbar at the same time (leaving users with no way to navigate). Have to duplicate targeting logic across related flags.

Schema versioning

Hypertune

Pin clients to a specific schema version so breaking changes, like removing a flag, don't break production.

LaunchDarkly and others

No schema or schema versioning. If you remove a flag without removing its usages, your clients will break in production.

Built for reliability, performance and flexibility

Hypertune

Only query the flags you need at SDK initialization. Get auto-generated code based on this query.
All flag getters are synchronous.
Type-safe GraphQL API, based on your schema, to query flags from any client without using an SDK.

LaunchDarkly and others

All flags are fetched at SDK initialization.
Some SDKs use asynchronous flag getters which risk your code hanging due to a promise that never resolves.
No type-safe API to query flags from any client.

Powerful A/B testing, machine learning and funnel analytics

Hypertune

A/B tests are a first-class citizen. Drop them anywhere in your logic. Reuse a single A/B test across multiple flags, e.g. run a "Rebrand" test across newNavBar, newLogo and colorTheme.
Make A/B tests multi-dimensional. Use different dimensions on different flags to find the best combination of flag values.
Nest A/B tests inside each other. Run mutually exclusive tests on randomly split, distinct segments of the population. Set up a long term holdout across many shorter term tests.
Nest logic within A/B test branches, e.g. to test personalized content or dynamic pricing.
Break down A/B test results by user attributes and any other features you log.
Create a machine learning "loop" to automatically find the best flag value for a given user or set of features. Make it multi-dimensional to find the best combination of flag values.
Build a funnel from your events, A/B tests and ML loops to see drop-off and conversion rates broken down by user attributes and other features.

LaunchDarkly and others

A/B tests are tightly coupled to flags. Can't reuse a single A/B test across different, related flags.
Can't make A/B tests multi-dimensional.
Can't nest A/B tests inside each other.
Can't nest logic within A/B test branches. Forced to make code changes to test personalized experiences.
Can't break down A/B test results by any feature.
Can't automatically optimize flags and configuration for a given user or set of features.
No funnel analytics to see drop-off and conversion rates across multiple steps.

Scales to all of code configuration, not just flags

Hypertune

Manage permissions like what features a user has access to given their organisation, plan, role, manual overrides, etc.
Use for rich backend configuration like clusters, queues, cron jobs, metrics, alerts, search and ranking systems, complex versioning, LLM prompts, etc.
Platformize your backend services to empower stakeholders to add new cron jobs, alerts, etc, themselves.
Manage magic numbers like pool sizes, timeouts, intervals, retry counts, backoffs, delays, sampling rates, TTLs, thresholds, limits, batch sizes, ranges, lookback periods, etc.
Manage environment variables like hosts, ports, URLs, local file paths and directories, third-party party app IDs, IDs of objects in other systems (like Stripe price IDs), process names, valid file formats, logging levels, etc. Use build-time mode for instant, guaranteed SDK initialization.
Use as a rule and decision engine to manage eligibility checks, automate approval claims, decide whether certain products can be fulfilled, etc. A/B test rules or use ML to optimize decisions. Assign granular permissions to stakeholders.
Manage pricing plans, discounts, limited time offers and promo codes. Optimize pricing to maximize revenue.
Manage in-app content like onboarding copy and checklists, guides and templates, tooltips and error messages, signup and upgrade flows, and modals and banners.
Optimize landing page content for each unique visitor with AI.
Use for type-safe funnel analytics. Define event types and their arguments in your strongly typed GraphQL schema. Log events with their arguments in a type-safe way in your code. Build an analytics funnel to see drop-off and conversion rates.

LaunchDarkly and others

Can't use to manage permissions.
Can't use for rich backend configuration.
Can't use to platformize backend services.
Not designed for managing magic numbers.
Can't use to manage environment variables.
Can't use as a rule and decision engine.
Can't use to manage pricing plans.
Can't use to manage in-app content.
Can't use to optimize landing page content.
Can't use for type-safe funnel analytics.