Show HN: Hypertune – Visual, functional, statically-typed configuration language (hypertune.com)

Hey HN! I'm Miraan, the founder at Hypertune, and I'm excited to be posting this on HN. Hypertune lets you make your code configurable to let teammates like PMs and marketers quickly change feature flags, in-app copy, pricing plans, etc.

It's like a CMS but instead of only letting you set static content, you can insert arbitrary logic from the UI, including A/B tests and ML "loops".

I previously built a landing page optimization tool that let marketers define variants of their headline, CTA, cover image, etc, then used a genetic algorithm to find the best combination of them. They used my Chrome extension to define changes on DOM elements based on their unique CSS selector. But this broke when the underlying page changed and didn't work with sites that used CSS modules. Developers hated it.

I took a step back.

The problem I was trying to solve was making the page configurable by marketers in a way that developers liked. I decided to solve it from first principles and this led to Hypertune.

Here's how it works. You define a strongly typed configuration schema in GraphQL, e.g.

  type Query {
    page(language: Language!, deviceType: DeviceType!): Page!
  }

  type Page {
    headline: String!
    imageUrl: String!
    showPromotion: Boolean!
    benefits: [String!]!
  }

  enum Language { English, French, Spanish }

  enum DeviceType { Desktop, Mobile, Tablet }

Then marketers can configure these fields from the UI using our visual, functional, statically-typed language. The language UI is type-directed so we only show expression options that satisfy the required type of the hole in the logic tree. So for the "headline" field, you can insert a String expression or an If / Else expression that returns a String. If you insert the latter, more holes appear. This means marketers don't need to know any syntax and can't get into invalid states. They can use arguments you define in the schema like "language" and "deviceType", and drop A/B tests and contextual multi-armed bandits anywhere in their logic. We overlay live counts on the logic tree UI so they can see how often different branches are called.

You get the config via our SDK which fetches your logic tree once on initialization (from our CDN) then evaluates it locally so you can get flags or content with different arguments (e.g. for different users) immediately with no network latency. So you can use the SDK on your backend without adding extra latency to every request, or on the frontend without blocking renders. The SDK includes a command line tool that auto-generates code for end-to-end type-safety based on your schema. You can also query your config via the GraphQL API.

If you use the SDK, you can also embed a build-time snapshot of your logic tree in your app bundle. The SDK initializes from this instantly then fetches the latest logic from the server. So it'll still work in the unlikely event the CDN is down. And on the frontend, you can evaluate flags, content, A/B tests, personalization logic, etc, instantly on page load without any network latency, which makes it compatible with static Jamstack sites.

I started building this for landing pages but realized it could be used for configuring feature flags, in-app content, translations, onboarding flows, permissions, rules, limits, magic numbers, pricing plans, backend services, cron jobs, etc, as it's all just "code configuration".

This configuration is usually hardcoded, sprawled across json or yaml files, or in separate platforms for feature flags, content management, A/B testing, pricing plans, etc. So if a PM wants to A/B test new onboarding content, they need a developer to write glue code that stitches their A/B testing tool with their CMS for that specific test, then wait for a code deployment. And at that point, it may not be worth the effort.

The general problem with having separate platforms is that all this configuration na...