One studio, one system: how design and dev speak the same language

The moment a client feels the difference is usually week three.

They will have been in six meetings by then — kickoff, discovery, a design review, an engineering review, a stakeholder walk-through, a scope conversation. They will notice, without us pointing it out, that the same three people have been in every meeting. The designer is speaking about components the way the developer speaks about components. The PM is describing the flow in the same words the designer used. Nothing is being translated.

That is not a personality quirk of a small team. It is the whole point of running as one studio on one system. Here is what that means in practice, why it produces work that two vendors cannot, and where the leverage actually comes from.

The two vendor problem, briefly

Before the positive version — the failure mode we are replacing.

The default way most companies buy software is two vendors. A design agency draws the product. Six weeks later, a dev shop builds it. The design agency ships a Figma file with 400 frames. The dev shop looks at it, says "ah, but that button's not real", and re-decides half of it — spacing, states, breakpoints, animation, empty states, loading states, everything Figma doesn't do. The client gets a product that resembles the Figma but isn't it, and no one is fully accountable for the delta.

Every studio that operates this way is fighting the same problem without naming it: the design system and the code system are two different systems. The translation between them is where the value leaks.

We built our version of a studio to close that gap. Not by having designers and developers sit near each other — everyone claims that. By having them share one system.

What "one system" actually means

Four specific things are shared across every person on a project. Not three, not five. Four.

1. One set of tokens. Every color, every space value, every type step, every radius, every shadow lives in one place. In our work that place is a set of CSS variables in the code repo, mirrored 1:1 into the Figma library. When the designer opens Figma and picks a color, that color is var(--brand). When the developer writes Tailwind, that same value is bg-brand. Neither of them is guessing. Neither of them is naming their own version. When the brand orange changes, it changes in one place.

2. One component vocabulary. Button primary. Button secondary. Section. Container. Card. Badge. The words the designer uses in a review are the words the developer types into an import statement. There is no "the pill thing at the top of the page" — there is a <Badge>, and it has three variants, and both people know which one is being discussed.

3. One repo of truth. The code is the design system's source of truth, not the other way around. Figma reflects code. If a component doesn't exist in code, it doesn't exist. This inverts the default: instead of designers proposing things developers then have to build, designers propose from what already exists, and net-new components go through a shared exit — designed, coded, tokenised, documented, added to both surfaces at once.

4. One vocabulary for the whole team. PMs, content people, designers, and developers all use the words the system uses. When a PM writes "the CTA sits in the hero at desktop, moves under the subhead on mobile", everyone reading it knows exactly which component is where, without a screenshot.

Those four things sound like table stakes. In practice, most teams have zero of them, one at best. Building all four takes real discipline. Once you have them, the delivery curve changes shape.

What one system changes in the work

The four things above translate into four things a client can feel.

Efficiency. Fewer meetings. Reviews are shorter because the decisions being made are smaller — no re-litigating whether a card should have 12px or 16px padding when the token says 16. Handoffs between design and dev take minutes, not days, because the handoff is implicit: the design was drawn from the code.

Consistency. The tenth page a new team member ships still looks like the first page you saw. Not because they memorised the brand — because the system produced both.

Scalability. New features slot into place. A new page composes from existing components. A new team member (designer or developer) is productive in days because the vocabulary they need to know is finite and lives in one place. Adding a new brand surface — a mobile app, a Shopify store, a marketing site — is a composition problem, not a redesign problem.

Shared language. The most valuable and least visible one. Every person on the project can walk into any meeting and make sense of what everyone else is talking about. PMs, designers, developers, content — one language across all of them means no translation tax, which means fewer misunderstandings, which means less rework.

What the two-vendor comparison looks like

	Design agency + dev shop	One studio, one system
Sources of truth	Two (Figma + code)	One (code, mirrored to Figma)
Handoff artefact	300-frame Figma file	Live component library
Who owns a bug	"That's a design issue" / "That's a build issue"	One team
Change to the brand	Update Figma, hope dev catches up	Update tokens, propagates
New hire onboarding	Learn two systems	Learn one
Time to first working screen	Weeks	Days
Cost of a design change at week 8	High	Low
Failure mode	Translation loss between the two	Under-investing in the system early

The pattern is consistent every project we've run this way. The first few weeks are slower — building the system costs real time. Every week after that is faster. Around week 4 the curves cross. By week 12 the studio-with-a-system model is shipping features the two-vendor model is still designing.

Where the model doesn't apply

We are honest about the shape's limits.

Very small work. A single landing page, a logo, a one-off marketing asset — the overhead of a shared system is not worth it. Design it, ship it, move on.

Rescues of an existing codebase with a mature design system. If the client already has a working component library and a design team using it, we join the system rather than replace it. The whole point is not to be attached to our system; it's for the client's work to have one.

Engagements with a single skill. A pure engineering rescue, a pure branding project — those are legitimate single-discipline engagements, and paying for a full studio for them is inefficient.

For everything in between — new products, rebuilds, ongoing product work — one studio on one system is the shape we run, because it is the shape that lets a small team ship work that looks like a much larger one did it.

The answer

Two vendors will always be two systems, whatever the marketing says. One studio, on one system, produces work with fewer meetings, fewer handoffs, fewer surprises at launch, and a smaller total spend over the life of a product. It also produces a codebase and a design library the client can keep using long after we're gone.

If you want to see how the model plays out on a specific project, see how we run our services or send us a short brief. We reply within one business day.