Design systems for Rails teams. Built so the components in Figma, the components in your codebase, and the components your AI coding agents generate are all the same components.
Your design system probably lives in two places: the Figma file and the codebase. They are almost never the same.
Over eighteen months you accumulate three versions of every button, six shades of blue, tokens defined in CSS that do not exist in Figma, and components composed in Figma that have no implementation in code. At that point the design system is two systems sharing a name.
The AI tooling that now writes UI code makes the problem worse. The agent reads your codebase, sees four button components, picks one at random, and ships. The design system you spent a year building is no longer the system the team is shipping against.
What we build
A design system that has one canonical token source, projections to every surface that needs them, and clean round-trip between design tools and production code.
In practice:
- A canonical token source. Authored in DTCG-in-YAML, the W3C standard. Covers colors, typography, dimensions, durations, shadows, references, and the long tail of tokens that other tools drop. Everything downstream (CSS or SCSS, Figma variables, AI tooling references) is generated from this one source.
- Multi-tool adapters in a star topology. The canonical token source drives Figma, Penpot, Pencil, or whichever design tool the team uses. Each tool is a spoke. The tools never sync to each other, only to the canonical. This keeps multi-tool conflicts tractable.
- Per-token ownership and per-group conflict rules. Design-led tokens (color, type) let the design tool win in conflicts. Engineering-led tokens (z-index, breakpoints, spacing scale) let the code win. Per-token granularity means only real conflicts surface in PRs.
- ViewComponent and Code Connect bindings. Built components in code map to built components in Figma. Approved-but-not-built components render as labeled "Proposed" frames in the design tool until they ship. No more silent gaps between what the designer composed and what the developer can use.
- DESIGN.md as the portable projection for AI agents. AI coding agents need a structured design-rule reference, and the Google Labs DESIGN.md spec is the emerging interchange. We generate DESIGN.md from the canonical token source so Claude Code, Cursor, and similar tools read the system without anyone hand-maintaining a parallel reference.
How the engagement runs
A design system engagement runs in four phases.
Phase 0: Token canonical. Bootstrap your existing token system into a DTCG-typed canonical source. Generate the new SCSS partial alongside the old one and gate them for parity. No visual changes until parity holds.
Phase 1: Tool round-trip. Stand up the design tool adapter (Figma in most cases). Forward push from canonical to design tool. Reverse pull from design tool to canonical with 3-way merge and per-group ownership. Pick the design tool based on token fidelity at this phase if multi-tool is on the table.
Phase 2: Components. Manifest extractor for ViewComponent and similar libraries. Component sets generated in the design tool, bound to variables. Code Connect mappings for built components. Proposed components rendered as labeled placeholders.
Phase 3: Lockdown. Token parity check and design-system audit go blocking in CI. Swap the generated SCSS in for the hand-authored one. The system is locked.
Who this is for
Rails teams with three or more developers touching UI, where the lack of a real design system is starting to cost more than building one. Brand-conscious teams whose marketing surfaces and product surfaces are starting to drift. Teams using AI coding tools for UI work who want the agents to use the team's system instead of making up substitutes.
Not the right fit
You have a single developer building the UI. The friction tax is not high enough yet for a design system to pay for itself.
The team wants Tailwind utility classes as the design system. We can implement what you want, but the round-trip and AI-fluency thesis is built around tokens, not utility classes. Tailwind teams sometimes outgrow that decision, and we can help with the conversion when they do.
Brand has not been figured out yet. A design system is downstream of brand. We can run the brand work first as a brand-to-product continuity engagement, but pure design system engagements assume the brand and aesthetic decisions have already landed.
Investment and timeline
Engagements run six to twelve weeks for a focused scope (token canonical, Figma round-trip, initial component set). Larger systems with multi-tool support, deeper AI-tooling integration, and CI lockdown run twelve to twenty-four weeks. Investment is typically $40K to $120K, scoped per system.
Proof
We have built design systems for Rails teams since the Procore component system in 2014. The specific approach described here is being built now inside Talos as a working reference. The full Talos case study lands when the system reaches Phase 3 lockdown (estimated mid-2026).
Start a conversation
If your design system is drifting between Figma and production, or if your AI coding tools are making up styling that should come from the system, get in touch. Smaller diagnostic available: the UI Coherence Diagnostic ($2,500, one week) can identify drift severity and where the worst gaps are before a fuller engagement.
