Building Arbor · Part 1

Structure, not house style

Steven Neamonitakis

Ink drawing of a six-bay arcade of identical semicircular arches. Each bay is filled with a different pattern: diagonal hatch, empty paper, cross-hatch, ruled grid, loose wash, horizontal stripes. Seven vertical vermillion column axes and one continuous vermillion baseline run behind the entire arcade, shared by every bay.
Every bay is filled differently, but they all sit on the same axes. That’s the idea of this series: standardize the structure and let the surface vary. Illustration made with an image model.

Part 1 of Building Arbor, a series about my year on Linktree’s design system.

A company that moves fast eventually pays a fragmentation tax. Multiple teams, multiple products, one brand. Unless there’s 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. I measured success by whether teams shipped faster and more consistently than they did without the system, not by how many components we shipped. Coverage was easy to count. Trust was what mattered.

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 all the same idea:

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. A reviewer approving a release. Same knowledge, delivered where the decision happens, instead of sitting in a document someone was supposed to remember.

The rest of this series is how I built each one.

Up next