# Your design system, inside every AI coding tool

> OnBrand UI for teams: UI components served to your developers' AI tools over MCP, themed to your design tokens and limited to a set your admins approve.

Source: https://onbrandui.com/teams

---

OnBrand UI for teams

# Your design system, inside every AI tool your team uses.

Your developers already use Claude Code, Cursor and Copilot to build interfaces. OnBrand UI makes sure what those tools install looks like your product, meets your accessibility bar and comes from components your design team has approved.

## What an admin controls

### The theme

One set of tokens for colour, type, spacing, radius and shadow. Every component the AI tools install is generated from it, so a change of brand colour reaches new work without anyone editing components by hand.

### The approved set

Switch components on for the organisation and the AI tools can only choose from those. A request for a "date picker" gets your approved date picker, not whatever the model remembers from its training data.

### The accessibility floor

Each component is tested against WCAG 2.2 AA before it enters the library: keyboard paths, visible focus, labelled controls and contrast checked against your theme's colours, not just ours.

### Seats and access

Add and remove developers from one place. Contractors and agencies working on your product get the same components and theme as your own team for as long as they have a seat.

## Why a written style guide isn't enough

The common fix is a rules file: a page of instructions telling the AI tool which colours and components to use. It helps, but the tool still writes the component from scratch each time, and it reads the whole file on every request.

When Atlassian [compared approaches](https://www.atlassian.com/blog/ai-at-work/atlassians-design-md-is-here-what-we-learned-testing-portable-design-context-in-practice), their MCP server did better than a design file and used far fewer tokens. OnBrand UI takes the same route: the tool asks for a component by name and receives finished code, instead of being told how to write it.

## Questions from teams

### Can we use our existing design tokens? +

Yes, that is the intention. You will be able to import tokens as JSON or from Figma variables, or set them by hand. Every component then reads from that theme.

### How do admins control what AI tools can install? +

Admins switch components on or off for the organisation. When a developer's AI tool asks for a component, it can only choose from the switched-on set, so a tool cannot pull in something your design team has not approved.

### We already run a private component registry. Why would we need this? +

A registry hosts components you have already built. OnBrand UI provides the components, themes them to your brand and adds the approval layer on top. If you have a mature in-house library, we would like to hear what you would need from us: register your interest below.

### Do we own the code that gets installed? +

The component code is written into your repository as source, so it is yours to change. The licence will let you use it in your own products, and not resell the components themselves. Full terms will be published before launch.

### When will team plans be available? +

Team plans are in development. Register your team's interest and we will contact you before early access opens, so your requirements shape what we build first.

## Register your team's interest

Tell us about your team and the tools you use. We'll be in touch before early access opens, to understand what you'd need from it.