Feature flags are just the tip of app configuration

Feature flags are pretty cool. They let you change the behaviour of your app at runtime, without code changes or redeploys.

And they're not just static true or false values. You can define logic based on the current User, Environment, Organization, etc.

But they're not limited to feature rollouts. You could use them to control feature access in a more permanent way, i.e. for entitlements.

Instead of enabling a feature for groups of beta users, you can enable it for users on certain plans:

They're also not limited to boolean on/off toggles for feature access.

If you returned a number from the flag instead of a boolean, you could use it to control usage limits, like how many API requests a user can make or how many seats an organization has.

If you returned an enum, you could use it to control feature modes like which AI model to use.

If you returned a string, you could use it to control the prompt to pass to the model, or the copy to display in your app.

If you returned an object, you could return many related flags together, like the model, prompt, temperature, and max tokens. Or an in-app modal's title, message, and CTA.

If you returned a list of objects, you could return a feature matrix for your in-app pricing page, or the list of benefits that appear on your landing page.

App configuration is much broader than just feature flags. The use cases span across:

And a large long tail of niche use cases.

But they all share the same benefits:

Traditional feature flag tools weren't designed for app configuration

Unfortunately, tools today were only designed for basic feature flags, so they have large architecture gaps that make them unsuitable for broader app configuration:

Lack of static typing and type safety

Flags are referenced as raw magic strings in code, with untyped return values. This is particularly bad for non-boolean flags like enums and objects.

Typos in flag names aren't caught at compile-time, and can cause runtime errors in production. Missing or mistyping enum cases in code is even worse as your logic will fail silently.

IDE features like code completion, find references, and JSDoc tooltips don't work.

Editing JSON flags incorrectly from the dashboard can cause your app to crash at runtime if not handled properly in your code.

Context like the current User, Organization, Environment, etc, are passed as untyped objects. Targeting rules in the dashboard can reference nonexistent properties and fail silently.

Lack of Git versioning

Flags have separate version histories so it's hard to debug and recover from bad combinations of changes to multiple flags.

There's no branching, so you can't preview flag changes. And you can't carry out refactors like removing or renaming flags or context properties.

Neither you nor AI agents can edit your configuration logic as code.

Inflexible logic

You can't insert experiments within targeting rules, e.g. to run experiments on specific user segments.

You can't insert targeting rules within experiment arms, e.g. to experiment with dynamic content or a dynamic model choice.

Although JSON flags are commonly supported, you can only insert rules at the top level; you can't insert logic within the object, e.g. on a specific field.

You can't exhaustively match on an enum input, e.g. the user's subscription plan, to return a flag value for each plan.

You can't define flag-specific inputs, e.g. `price_id(usage: Int!): String!`

All context must be passed at the top level.

Not AI friendly

As AI agents take over more of the development, they'll commit more code, faster, and the problems caused by lack of type safety and Git versioning will only worsen.

Hypertune

We built Hypertune to fill these gaps and become the single platform to configure, analyze, and optimize your app.

At the core of Hypertune is a functional, statically typed configuration language we designed called Hyperlang.

When you edit rules in the dashboard, you're editing the AST of your Hyperlang program.

It's designed specifically for configuration, with:

The SDK fetches your configuration logic on initialization and interprets it locally when you use flags in your code.

The interpreter is architected for configuration too:

The Hypertune CLI autogenerates a type-safe client to pass context arguments and access your flags.

And all your configuration is versioned in a Git-style history, with branching, pull requests, team roles, approval workflows, and the option to connect your own Git repo with a bidirectional sync.

Today, Hypertune is used for a broad range of configuration use cases by companies of all sizes from startups to large enterprises.