Rebuilding the data layer from scratch

Background

Kolora came to Blite with a clear problem: design teams were making color decisions in isolation, with no shared source of truth and no systematic way to evaluate contrast, accessibility, or brand consistency at scale. Their existing tooling was a patchwork of spreadsheets and plugins that broke on every handoff.

The underlying issue was the data itself, not the tooling. Color decisions were stored implicitly in design files, not extracted into a queryable format. There was no way to ask “which surfaces use this token?” or “what fails WCAG AA?” without opening every file by hand.

What we built

We designed and built the Kolora platform from scratch: a color intelligence system combining a token-based design system with real-time accessibility analysis. The core engine evaluates contrast ratios, generates accessible palettes, and flags violations before they reach production.

Token extraction pipeline

The first layer is a sync pipeline that pulls token data from Figma’s Variables API on every design file save. Tokens land in a normalized schema (name, value, type, semantic role) and are versioned at the commit level. Any diff between commits surfaces as a structured changelog that design and engineering both read.

Accessibility engine

The engine evaluates every foreground/background pairing in the active token set against WCAG 2.1 AA and AAA. It runs on every sync, surfaces violations inline in Figma via the plugin, and blocks the export step if AA failures exist. The rule set is configurable per project: some clients need AAA on body text, others need adjusted thresholds for large display type.

Export and integration

The system exports to any design token format: W3C DTCG, Style Dictionary, Theo, or raw JSON. A GitHub Action runs the export on every merge to main and opens a PR in the consuming repo with a structured diff. Engineering never manually copies tokens.

{
"color.primary.900": {
  "value":   "#0A0A0A",
  "type":    "color",
  "role":    "brand-primary",
  "wcag": {
    "aa":   ["color.neutral.50", "color.neutral.100", "color.neutral.200"],
    "aaa":  ["color.neutral.50", "color.neutral.100"]
  }
},
"color.primary.500": {
  "value":   "#525252",
  "type":    "color",
  "role":    "brand-secondary",
  "wcag": {
    "aa":   ["color.neutral.50"],
    "aaa":  []
  }
},
"color.neutral.50": {
  "value":   "#FAFAFA",
  "type":    "color",
  "role":    "surface-default"
}
}

Tokens land in a normalized, versioned schema. Each token carries its value, type, semantic role, and the set of backgrounds it's valid against for WCAG compliance.

Before and after

Outcome

Kolora shipped on schedule. In the first quarter after launch, their design teams reported a 70% reduction in accessibility-related rework. The token export system became the foundation for all their product surfaces across web, iOS, and Android.

What the numbers show

In the 90 days after launch: 0 accessibility regressions shipped to production, down from an average of 12 per sprint. Design-to-engineering token sync went from a 2-day manual process to a 4-minute automated run. Three product surfaces (web, iOS, and Android) are now guaranteed to be in sync after every release.

What Kolora said

We used to find accessibility issues in QA. Now we find them before the design is ever handed off. That’s a different class of problem.