How to structure color tokens for a SaaS product so your palette scales across themes, components, and teams without entropy.
Primitive tokens are your raw color values: blue-500, gray-100, red-600. Semantic tokens map those to roles: surface-default, text-primary, border-subtle. Component tokens reference semantics for specific UI elements: button-primary-bg, input-border-error. This three-layer system means a theme change only touches the semantic layer — components don't know or care about the raw values underneath.
Avoid naming tokens after their visual appearance. 'Blue-cta' breaks when marketing decides the CTA should be orange. Instead use role-based names: action-primary, feedback-success, surface-elevated. ColorArchive's token export follows this convention by default, generating names that communicate purpose rather than hue. This makes your token file readable even to developers who weren't part of the original design process.
Once tokens are defined, distribute them through your build pipeline. CSS custom properties for web, JSON for React Native, and Tailwind config extensions for utility-class workflows. ColorArchive generates all three formats from a single palette. Version your token file in git alongside your component library so changes are tracked and reviewable — color changes should go through PR review just like code changes.
Move from the guide into a concrete palette lane
Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.
