Figmaless · Design system governance
Datum: Next-Gen Design System
Built in code for AI agents, crafted for humans.
I built Datum so the codebase is the only source of truth.
Designers direct the build from the terminal. No Figma during the build.
Built for enterprise-scale, multi-product, multi-brand teams, on best practice from Polaris, Carbon and Material.
Products consume it, agents query it over MCP, and every change is checked before it ships.
Claude Code is my tech lead; I set the rules and direction, and hold the gate.
Technology stack
At a Glance
Most teams keep a design file and a codebase for every product, then spend their time keeping the two in sync. Datum moves the source of truth into code — one system that people read in Storybook, agents read over MCP, and products extend without rewriting it.
Duration
Since June 2026 · named Datum in September · ongoing
Role
Architect and owner · Rule author · Human-in-the-loop gate
Scope
Foundations · Tokens · Components · Product layer · Governance tooling · MCP
Scale
485 colour tokens · 24 base components · 31 releases · 8 MCP tools
PROBLEM
Every product kept two truths, and they drifted.
A design file and a codebase per product means two sources of truth, maintained by hand. At Ratehub, nine years of that left 25 structural flaws in the foundation. Each new product multiplies the drift, and keeping Figma in sync becomes a job of its own.
Same component — Figma and production code no longer reflect each other.
A naming-convention crisis at the foundation level.
SOLUTION
One source of truth, in code. Everyone reads from it.
Designers and developers read Datum in Storybook, and agents read it over MCP. It changes only through a reviewed pull request.
STRUCTURE
Five layers, each with one job.
Foundations → Tokens → Components with contracts → Product layer → Governance.
Datum’s Storybook: every layer in one place.
THE ARC
Validating Datum: build with it
Four pushes, each one harder than the last.
Each stage tested something the one before couldn’t: one component, then a live product, then a complex one, then many brands. Every build is intentional. None of them was a separate experiment.
01 · ONE COMPONENT
Checkbox: every value a Datum token, from the first line.
Start small and strict. A checkbox built straight from Datum’s foundations, then run through the governance check: two raw values surfaced, an off-grid 5px corner and a hex fill, and both were lifted to tokens. Now 13 of 13 values resolve by name, traced from utility to semantic to primitive to the line in the source.
02 · A LIVE PRODUCT
Luxi Math: an off-system app, brought back to the system.
Harder: an app that already existed, built outside Datum. Luxi Math is a kids’ maths app, live at math.luxi.land. Screen by screen, raw values went back to Datum names and every state was contrast-checked with real input. Seven components so far, about three-quarters of the app; the rest is waiting on time, not on the system. The station popup went from 45 fails to 0 across 413 checks, shipped live.
03 · A COMPLEX PRODUCT
Analytics: a dense product, every component governed.
Harder again: precision at product scale. Analytics is a data-reporting reference product with demo data, built new on Datum: charts, tables, navigation. All 10 of its components read tokens, with 0 raw values. What only Analytics needs lives in its own tokens; what every product could use went back to Datum through a reviewed release, like one button-size scale.
04 · MANY BRANDS
Multi-brand: one colour in, a whole brand out.
The last push: the same product in many brands, with the process automated. Give Datum one colour and it generates the brand and checks every pairing for WCAG AA. Three brands are live on Analytics. People still choose the colour, set the rules and approve the merge.
Watch the brand change
Three live brands on the same screens.
WHERE IT LANDED
Multi-product, multi-brand, and almost all automated.
Every push was intentional, and every one shipped. Datum now carries two products and three brands, and the repeatable work runs on its own: generating, checking and documenting. What stays human is judgement: the rules, the look and the gate.
KNOWN GAPS
Written down, not hidden.
Pressed states need a neutral overlay (planned). Light brands need dark-text buttons. No dark mode yet. Luxi Math still holds local copies of some tokens.
Brand tokens live in Analytics until a second product needs them. Badge and Input aren’t on the contract yet.
Each one is documented alongside the system.
REFLECTION
Credits
Built with Claude Code (Nathan) as tech lead and Finn (Claude) reviewing. I authored the rules — the codebase as the source of truth, a contract for every component, products that extend but never rewrite — and held the gate on every merge.