Structure, Not House Style

This is Part 1 of Building Arbor. A series about the design-system work I did on Arbor at Linktree, written in retrospect.

A company that moves fast eventually pays a fragmentation tax. Multiple teams, multiple products, one brand. Unless there is a shared foundation underneath, every team quietly rebuilds the same button, the same form field, the same decision, slightly differently each time. Design and engineering drift apart. Quality starts to depend on who happened to build a thing rather than on the system they built it in.

Arbor, Linktree’s design system, exists to pay that tax down. But the framing I care most about isn’t “component library.” It’s product infrastructure — the shared foundation that lets design and engineering build the same thing without translating between them first. When it’s working, it disappears into the background.

Structure, not house style

The most useful thing I internalized working on Arbor is that a design system’s job isn’t to standardize expression — it’s to standardize structure, so expression can scale safely. A platform can host wildly different content and still feel coherent, precisely because the architecture underneath is rigorous even where the surface is free.

That reframing changes what you optimize for. Success isn’t the number of components shipped. It’s whether teams ship faster, more consistently, and with more confidence than they did without the system. Coverage is a vanity metric; trust is the real one.

The thesis of this series

Over the next few posts, I’m going to describe a set of things I built — a research capability, a Figma plugin, an orchestration layer, a code reviewer. It’s easy to read them as four side projects. They’re not. They’re one idea wearing four disguises:

Take the system’s knowledge — the tokens, the voice, the decisions, the accessibility rules — and put it in front of whoever is deciding, at the exact moment and place they’re deciding.

A designer deciding in Figma. An engineer deciding in a pull request. Anyone reading the docs. An agent writing UI. Same knowledge, delivered where the decision happens, instead of sitting in a document someone was supposed to remember.

That’s the spine. Everything else is how.