Design systems: For products built fast, and built with AI

For teams whose product works but no longer looks or behaves like one product, often because several people and their coding agents built it quickly. I take an inventory of what the product actually ships, fix the system it should be built from, and make that system something your engineers and their agents follow.

Start with
A Consistency Review, 3-4 working days
Price
From $1,500, fixed before we start
Then
Work on the system, priced by scope
For
Founders, CTOs, product teams

To start, email andriy.dsgn@gmail.com with a link to the product and a line about what feels off.

When teams bring me in

Usually at one of three points:

  • Several people and their coding agents built the product fast. Each screen looks fine. Together they ship several button styles and more than one way to do the same thing.
  • The product is about to get a second surface, a new team or new engineers, and nothing tells them which component is the real one.
  • A design system exists in Figma, and the code has moved on without it.

The Consistency Review

The fixed-price first step. I take an inventory of what the product ships: every component variant, every value outside the token set, every style used once or twice. Then I decide which differences are mistakes and which are intended. You get:

  • The inventory, grouped by component, with screenshots.
  • The fixes that matter, ranked by how many screens each one touches.
  • A task list your engineers or your coding agent can work through, one change per task.
  • A short note on whether the problem is the screens or the system behind them.

It is not a redesign and adds no new screens. From $1,500 for one product, fixed before we start, in 3-4 working days. Credited in full to the next piece of work if it starts within 30 days.

Fixing or building the system

When the problem is the system, I fix it or build it: tokens, components described for people and for agents, the rules file your agents read, and a check of what ships against it. Code is the source of truth and Figma is where the design work happens, so the two stop drifting apart.

Priced by scope, as a fixed project or as part of fractional work. I write frontend code, so I can make the changes in your repository or hand them to your engineers as tasks.

How I build systems for agents

A system that agents build from needs a few things a system for people could skip:

  • Code as the source of truth. Tokens and components live in the repository; Figma is where the design work happens and gets synced back, so names never break between the two.
  • Descriptions written for agents. Every component says what it is for, when not to use it and which one to use instead. An agent reads that before it reads the props.
  • A rules file, tested. The rules your agents read are checked against real tasks: an agent builds a screen from them, and every place it guesses becomes a new rule.
  • A Figma file an agent can read. An agent audits the design file: layer names, component descriptions, token bindings, so design-to-code reads intent rather than geometry.
  • Checks on what ships. A token audit and an inventory of the running product find what drifted, and the fixes go back to the agent as tasks.

Why agents need a system

An agent is good at one screen. Across a product it repeats whatever it finds, mistakes included, and when the system does not answer its question, it invents a value. A design system used to be documentation for people. Now it is also what your agents build from, and what their output gets checked against.

On a test app I had an agent build in one evening, the inventory found 21 button styles across 25 screens. How that review works: A canvas for reviewing AI-built UI.

What a system changes once agents write the UI, measured on 11 agent builds with no system, on shadcn/ui and with rules an agent reads: Design systems for coding agents.

Where this comes from

A design system for every product I have worked on, dozens over 14 years, from one product’s component library to multi-brand systems with themes, tokens in two tiers and components in code. The ones I can show:

  • Volterra, 2017-2021, acquired by F5 for $500M (announced in January 2021). I built the design system the whole design team worked from and reviewed the other designers’ work.
  • Deva and 10Planet, 2022-2025. One design system for both, mapped to the protocol’s objects: memory has a type, a task has an execution route, a vote has a scope. Handoff errors between design and engineering dropped by 40%.
  • Equi, 2021-2022, as the only designer. One Figma component library behind every screen, and development ran about 25% faster.
  • Fully AI, 2024. In one month: a UX audit, a token-based design system, a reorganized Figma workspace and a dashboard redesign.

Questions teams ask

Do you work in Figma or in code?

Both. Code is the source of truth and Figma is where design work happens. I write frontend code, so I can make the changes in your repository myself or hand them to your engineers as tasks.

We don’t have a design system. Is it too early?

Often it is. A startup with one product and a few engineers needs a small set of tokens and the components it actually uses, not a library. The review tells you which one you need.

Why not just use shadcn/ui?

It is a good start for a prototype. In my experience its tokens and interactions are not consistent enough from one component to the next, so a team ends up patching each one and remembering the exceptions. I build the system from one token logic and one set of interaction rules. It takes longer at the start. Afterwards the team, and its agents, can read the logic instead of memorising exceptions.

Which tools does this work with?

Products built with Cursor, Claude Code, Lovable, v0 or by hand. React with Tailwind is the most common case. Anything that runs in a browser can be reviewed.

How is this different from a UX audit?

A UX audit asks whether people can use the screens. The Consistency Review asks whether the screens are one product: whether the same thing looks and behaves the same everywhere, and whether it is built from the same parts. If the question is what to build at all, that is a Product Diagnosis.

How much does it cost?

The Consistency Review is from $1,500 for one product, fixed before we start. Credited in full to the next piece of work if it starts within 30 days. Work on the system itself is priced by scope.

Can you work under an NDA?

Yes.

Do you work with teams in other countries?

Yes. I work remotely, with teams in different countries and time zones.

Has your product drifted?

Send a link and a line about what feels off. If it’s not a fit, I’ll say so.