How Binder is built
The identity contract
Every color, radius, shadow, and font weight in Binder comes from one file we call the identity contract. This page documents what's in it and how it flows through the product. We wrote about why we built it this way on the blog — this page is the shorter, reference version.
What it defines
| Group | Examples |
|---|---|
| Color | background, surface, three text-ink levels, border line, one accent, good/warn/critical |
| Type | a display typeface for headings, a body typeface, a mono typeface, a scale ratio |
| Shape | a three-step radius scale, border width, shadow level |
| Space | one base unit every spacing value multiplies from |
| Voice | tone words and example microcopy, so writing stays consistent too |
Color and type are defined once for light mode and once for dark mode. Nothing else in the product is allowed to declare its own color, radius, or shadow outside of this file — components only ever reference a token, never a literal value.
The rules we don't break
The file also carries a short list of forbidden patterns: no gradients, no second brand color anywhere in the interface, no shadows on list rows or table rows, no colored left borders on cards. These rules matter as much as the palette does. They're what stop a product from slowly accumulating one-off exceptions until "the design system" is just a suggestion.
How a change propagates
Change a value in the identity contract and rebuild, and every component that reads that token updates together — buttons, links, focus rings, the logo, both themes. There's no second place to update. If a screen looks wrong after a change, the fix is almost never "patch that one screen" — it's "the token is wrong," which means the fix is correct everywhere at once.
Dark mode
Dark mode is the same contract, evaluated with its dark values instead of its light ones. We design both together, as two settings of the same file, so neither one is ever the "forgotten" theme.