Why Helix has two tiers

Docs

IntroductionHow to install and use Helix.InstallationWhat to install, in order.Deriving a themeTokens from your brand color.

Tools

SandboxEdit code, see the result.Theme builderA palette from your brand.Visual testingCompare pages with baselines.

Cortex Services Insights

Helix

Components

Cortex

Sandbox

Theme builder

Aura

Services

Contact

Insights

Thesis

↑

↓Move↵GoSandboxEscClose

Fusion

Preferences

System

Light

Dark

Off

Headless

Styled

HelixOverview

Components

Maps

Graph

Introduction

Installation

Deriving a theme

Sandbox

Theme builder

Visual testing

CortexDocs

EngramBuilding

TraceBuilding

RecallDeclared

Services

Insights

Get in touch

Source on GitHub

DesignDecision

Helix ships as one open tier

Every Helix component is free and open source. A paid tier would hide components from the AI agents that write code with Helix.

August 18, 2026

2 min

DesignEssay

A palette from one brand color

Helix computes its palette from one brand color. Contrast follows from how the colors are computed, so no one has to review each pair.

August 11, 2026

2 min

DesignEssay

Why Helix has two tiers

Large companies have many brands and frameworks. A team that needs a different look can use the headless tier and keep the same components, parts, and events.

July 28, 2026

5 min

EngineeringDecision

Lockstep versioning, one domain at a time

The packages in each domain, such as Helix, share one version number, so a Cortex fix does not change the version of the Helix docs.

July 14, 2026

2 min

Loading writing

Fusion

Helix

ComponentsEvery component and its API.MapsMaps in your brand’s colors.GraphGraphs in 2D and 3D.

Docs

IntroductionHow to install and use Helix.InstallationWhat to install, in order.Deriving a themeTokens from your brand color.

Tools

SandboxEdit code, see the result.Theme builderA palette from your brand.Visual testingCompare pages with baselines.

Cortex Services Insights

Helix

Components

Cortex

Sandbox

Theme builder

Aura

Services

Contact

Insights

Thesis

↑

↓Move↵GoSandboxEscClose

Fusion

Preferences

System

Light

Dark

Off

Headless

Styled

HelixOverview

Components

Maps

Graph

Introduction

Installation

Deriving a theme

Sandbox

Theme builder

Visual testing

CortexDocs

EngramBuilding

TraceBuilding

RecallDeclared

Services

Insights

July 28, 2026

Why Helix has two tiers

Large companies have many brands and frameworks. A team that needs a different look can use the headless tier and keep the same components, parts, and events.

An enterprise does not have one brand. It has a marketing site, six product surfaces on three different release cadences, an acquisition still running on whatever stack it was bought with, a partner portal somebody built in a hurry, and a brand refresh every three years that arrives as a PDF.

A single styled component library serves exactly one of those well. Everything else either accepts pixels that are wrong for it, or forks. This is the structural reason component libraries fail inside large organizations, and it is upstream of every governance conversation about it.

Helix is shaped around that fact rather than around the demo.

Two tiers, one vocabulary

The headless tier is behavior with no opinion about appearance: state, focus management, keyboard interaction, the accessibility contract, the parts that are genuinely hard and genuinely universal. The styled tier is the same components with a derived visual system on top of them.

They are not two products. They are one vocabulary with two levels of commitment. The same component names, the same parts, the same props, the same events, whichever tier a team is on.

What that buys is not flexibility for its own sake. It is that the fork now has a supported destination. A team that needs different pixels drops a tier instead of copying a file, and the copy is what the previous essay describes as the thing nobody is assigned to and no audit finds. Dropping a tier keeps the team inside the vocabulary, keeps the accessibility work, and keeps the upgrade path. Copying a file gives up all three at once.

For an enterprise this is the difference between one system with two adoption levels and two systems with a migration between them.

Tokens are derived, not authored

Most systems ship a palette as a spreadsheet: eleven steps of gray, eleven of the brand, a handful of status colors, each of them a hex somebody picked and nobody can check. The file is authoritative because it is the file, not because anything about it is true.

The problem is not that the values are wrong. It is that there is no procedure by which they could be found wrong. A contrast failure between two steps is discovered by a person running an audit, and the fix is another hex nobody can check. Accessibility becomes a review step, and review steps are what a deadline removes first.

Helix takes one brand color and computes the rest in a perceptual space, so lightness means the same thing at every hue and the contrast between two steps is a consequence of how far apart they are rather than a coincidence somebody verified once. A component asks for a named foreground and gets a correct value in light mode, in dark mode, and against whatever brand the consumer set.

The enterprise consequence is the one worth stating plainly: a rebrand becomes a value change rather than a project, and the accessibility posture survives it without a re-audit, because accessibility was never a property of the individual hexes. It was a property of the derivation.

Overrides land on a declared surface

Every real adoption needs to change something. The question is only whether the change lands somewhere with a contract.

A Helix component owns its surface and names the variables that tune it. A consumer sets those. A stylesheet reaching past them into internals is a finding the command line reports, not a clever workaround that ships and then freezes the system three years later.

That is the whole mechanism that makes a version bump safe. The system can change its internals because no consumer was ever supposed to depend on them, and the difference between a system that can be upgraded and one that cannot is exactly whether that sentence is enforced or merely believed.

Web components, so the framework question stops mattering

The four stacks in the paragraph at the top of this essay are the normal condition of a large company, not a symptom of poor planning. A React-only system asks that company to either standardize first, which is a multi-year program with no user-facing outcome, or to maintain a second system for everything else.

Helix ships web components with framework wrappers over them. React, Vue, Svelte, Angular, and no bundler at all are adoption paths rather than ports. The acquisition on a different stack gets the same vocabulary on the day it is acquired.

One open tier, and what that costs us

No pro components, no paywalled API surface, no enterprise build with three extra things in it. The economic argument for a paid tier is real and we are not pretending otherwise: it is how most component libraries fund themselves.

The architectural argument against it is stronger. Under cheap generation a system's value is being the constraint that generated code converges on, and a paywalled component is a component that generation does not know about. Split the vocabulary and you have not added a revenue line with a small cost attached. You have damaged the property that made the system worth adopting, silently, in a way that reads as the system being mediocre.

Payment lives in the engagement instead. We are paid for applying the system, which keeps making the system easier to apply aligned with revenue rather than opposed to it.

What the trade costs

Derivation is worse than hand-picking at exactly one job, which is hitting a specific value a brand guideline names. If the book says the disabled state is this gray and no other, a derived system will argue with you.

Web components cost some ergonomics against a shop that is genuinely React-and-nothing-else forever, and a few of them are real rather than imagined.

We think both trades are correct for a design system and would be wrong for a brand identity or for a single-application component library, which are different artifacts with different jobs. Helix is Building, not shipped, and the stage labels on this site say so.

Ross Sheppard

Keep reading

All insights

Design

2 min

Helix ships as one open tier

Every Helix component is free and open source. A paid tier would hide components from the AI agents that write code with Helix.

Design

2 min

A palette from one brand color

Helix computes its palette from one brand color. Contrast follows from how the colors are computed, so no one has to review each pair.

Engineering

2 min

Lockstep versioning, one domain at a time

The packages in each domain, such as Helix, share one version number, so a Cortex fix does not change the version of the Helix docs.

DesignDecision

Helix ships as one open tier

Every Helix component is free and open source. A paid tier would hide components from the AI agents that write code with Helix.

August 18, 2026

2 min

DesignEssay

A palette from one brand color

Helix computes its palette from one brand color. Contrast follows from how the colors are computed, so no one has to review each pair.

August 11, 2026

2 min

DesignEssay

Why Helix has two tiers

Large companies have many brands and frameworks. A team that needs a different look can use the headless tier and keep the same components, parts, and events.

July 28, 2026

5 min

EngineeringDecision

Lockstep versioning, one domain at a time

The packages in each domain, such as Helix, share one version number, so a Cortex fix does not change the version of the Helix docs.

July 14, 2026

2 min

Loading writing

All insights

Design

July 28, 2026

Why Helix has two tiers

Large companies have many brands and frameworks. A team that needs a different look can use the headless tier and keep the same components, parts, and events.

Helix is shaped around that fact rather than around the demo.

Two tiers, one vocabulary

They are not two products. They are one vocabulary with two levels of commitment. The same component names, the same parts, the same props, the same events, whichever tier a team is on.

For an enterprise this is the difference between one system with two adoption levels and two systems with a migration between them.

Tokens are derived, not authored

Overrides land on a declared surface

Every real adoption needs to change something. The question is only whether the change lands somewhere with a contract.

Web components, so the framework question stops mattering

One open tier, and what that costs us

Payment lives in the engagement instead. We are paid for applying the system, which keeps making the system easier to apply aligned with revenue rather than opposed to it.

What the trade costs

Web components cost some ergonomics against a shop that is genuinely React-and-nothing-else forever, and a few of them are real rather than imagined.

Ross Sheppard

Keep reading

All insights

Design

2 min

Helix ships as one open tier

Every Helix component is free and open source. A paid tier would hide components from the AI agents that write code with Helix.

Design

2 min

A palette from one brand color

Helix computes its palette from one brand color. Contrast follows from how the colors are computed, so no one has to review each pair.

Engineering

2 min

Lockstep versioning, one domain at a time

The packages in each domain, such as Helix, share one version number, so a Cortex fix does not change the version of the Helix docs.