One way for a designer's change to reach the product

What changes for engineering

A pull request arrives. That is the whole change. Reviewers need no seat and no account. The title is written for a reader, each change is listed old value to new, and the diff touches the lines that should have moved. Your branch protection, CODEOWNERS and required checks apply as always. A change the checks can see would touch behaviour was refused before it was written, so it never reaches review.

What is new on a designer's Mac, so nobody is surprised: the app, its own copy of the repository with packages installed from the lockfile, the AI tool your company already uses, and the designer's own GitHub sign-in. No change on any server.

Yes, a designer with Cursor could do this. Cursor will also write a raw hex, change a handler and touch twelve files. This refuses the first two and asks about the third.

Governance you already have

The approval system for a Something change is your Git. Branch protection decides who merges. CODEOWNERS decides who reviews. Required checks decide what must pass. The audit trail is the pull request history, in the system your company already audits. Something adds no approval system of its own and asks nobody to learn one.

There is no AI of ours to govern. The engine is your company's own Claude Code, Codex or Gemini subscription, under your agreement with that provider. We hold no key and sit in no path.

Your rules travel with the project. The CLAUDE.md or CONTRIBUTING.md your team already keeps is read before every answer, so the assistant works inside your conventions rather than its own. Roles keep a designer out of files they cannot judge; a refusal names which kind of engineer can take it on. That is a guardrail, not access control. Access control is your branch protection, and nothing goes around it.

The system stays true in code

Your tokens, your components, your patterns are what the tool offers, by name. A raw value that matches no token gets a question. A shared value says how many elements use it before anyone touches it. A design system in its own repository is linked to the product; a change to one of its components is made at its source, shown on the product, and sent as two pull requests from one branch, the system first.

Drift is not something to track afterwards. A change made here is made in the code the system is defined in, so it does not create any.

Open any component to see every size by state by scheme, from the code, and every file and line it is used from. "What breaks if I change this" has an answer before the change.

No server to host, no plugin to maintain

It runs on each designer's Mac. It works on your Git, your design system, your CI and your AI subscription. There is no server to run, no sync to babysit, no plugin to keep updated inside Figma. The one thing it adds to your repository is a small .something folder with the project plan, which your engineers can read and correct in a pull request.

What your security team will ask

Where does the code go?

It stays on the designer's Mac, in the app's own copy of the repository. The only thing that leaves is what the designer's own AI engine sends to your own provider, exactly as it does when a developer uses that engine today.

What does the AI see?

What your own AI sees already. The engine is the Claude Code, Codex or Gemini CLI sign-in your company already has, or your own key, under your agreement with that provider.

What reaches BAARS DESIGN?

Today, nothing. When accounts are live: name, email, sign-in times, subscription state, seats, and for team admins a monthly count of pull requests sent per member. Never the repository, file names, prompts or screenshots.

How does the pull request get to GitHub?

From the designer's Mac, under the designer's own GitHub sign-in, which lives in that Mac's keychain. BAARS DESIGN holds no token for your organisation and never has administrative access to it.

Security and privacy, one page to forward →

Who needs a seat

Trust builds in small steps

The first changes a team makes are small: a wrong word, a gap that is one step off, a colour that left the scale. Each is a one-line pull request reviewed in minutes, and each one makes a sceptical designer try the next. Something is built for that ladder. No change is written without being shown first. Every change can be taken back. None of it is lost to a crash, a lapsed card or a colleague's edit.

What it costs, and what it does not

You pay for the people who send changes. Nobody pays to review one. A team of five designers and twenty developers is five seats.

Compare that with what companies pay today for the gap between design and code. Figma's Dev seat exists so a developer can read a design: $25 a developer a month on Organization, $35 on Enterprise, billed yearly (figma.com/pricing, 30 October 2026). Here the developer reads a pull request, which costs nothing.

Figma's seats now come with a monthly AI credit allowance. Here the AI is your own subscription and we never count it. The price is a seat, not a meter. Team is $32 an editor a month billed yearly, $39 monthly. Enterprise is from $65 an editor a month, billed yearly.

This is not an argument for dropping Figma seats. Designers still explore there. It is the reason the developer side of this costs you nothing.

See pricing →

Enterprise

The Enterprise plan comes with a DPA with standard clauses, a completed security questionnaire, invoicing by purchase order on an annual contract, and a named contact. The contract is with BAARS DESIGN, a Norwegian company, org.nr 938 054 037. Account data will be stored in the EU.

On request, delivered as part of an Enterprise agreement: SAML or OIDC single sign-on, SCIM provisioning, audit-log export and domain auto-join. Tell us what you need and we will say what we can deliver on signature.

SOC 2: not yet. Ask us where we are with it and we will tell you.

Start with one pull request

The trial is 14 days of Team, no card. Enough for one real change to land in the company repository and be reviewed by the developer who will tell you whether it was worth it.