Skip to main content

The Upstream Advantage

Design System at Scale
Role
  • Principal Architect
  • Technical Lead
Stack
  • GitHub Actions
  • Jest
  • Visual Regression Testing
  • NPM
  • CDN
  • Monorepo

Invest Once, Benefit Many

The economics of shared systems

Here's the math that justified the investment: fix an accessibility bug once, and every site using the component gets the fix automatically. Optimize a bundle once, and every page load across the ecosystem gets faster. The value compounds with every adopter.

I designed for a future we couldn't predict. Would 50 sites adopt, or 500? The answer shaped every architectural decision: build the upstream infrastructure so well that adoption becomes inevitable, and every new adopter multiplies the return on investment.

Design system adoption graph

The Trust Problem

Why Shared Systems Fail

Testing pipeline diagram

Most shared systems fail not because of bad code, but because of broken trust. A team adopts a library, then an update breaks their site. They fork it, fall behind on updates, and eventually abandon it. The pattern repeats across organizations.

I designed against this failure mode with automation at every gate:

  • 1,032+ Jest tests across 48 suites run on every pull request before merge
  • Visual regression testing catches unintended styling changes
  • Lighthouse CI blocks releases that degrade performance or accessibility
  • Automated semantic versioning communicates breaking changes clearly

The goal: adopters can update with confidence. When teams trust that updates won't break their sites, they stay on the latest version. When they stay current, they get every improvement automatically. Trust enables the compound returns.

Granular by Design

Take What You Need, Leave the Rest

Package architecture diagram

Heavy dependencies kill adoption. If using one button means importing a megabyte of code, teams will build their own button. I structured the system so every piece stands alone.

Nine packages, each with a single job:

  • Tokens for brand values (useful even without the rest of the system)
  • Styles for layout and typography (works with any component library)
  • Elements for atomic pieces (compose your own patterns)
  • Components for complete solutions (drop in and go)

A team can adopt just the tokens package to get brand colors in their existing app. A year later, they might add components. The path from minimal to full adoption is incremental, not all-or-nothing. This patience pays off: teams that start small often become the strongest advocates.

View Repository

Earning Adoption

Value Over Mandates

Adoption pathways diagram

In a decentralized organization, mandates backfire. Tell autonomous teams they must use a system, and they'll find reasons not to. Show them it solves their problems faster than alternatives, and they'll advocate for it themselves.

We built multiple paths to value:

  • Content editors get a visual playground: configure components, copy the markup, no code required
  • Developers get NPM packages with TypeScript definitions and tree-shaking
  • Legacy systems get CDN script tags that work without build tools
  • Everyone gets documentation that answers questions before they're asked

The strategy worked. Teams that initially resisted became early adopters once they saw colleagues shipping faster. Word of mouth drove more adoption than any top-down initiative could have.