How design tokens create a translation layer between design decisions and code, enabling consistent styling across any platform.

From Figma to Production

UMD Design System

A token is just a key and a value. That's it. Brand red is #E21833. Base spacing is 8px. Body font is Source Sans. The simplicity is the point: there's nothing to misunderstand, nothing to configure wrong.

We export in every format anyone could need:

The real magic: when the brand team updates Maryland Red from #E21833 to something else (it happens), they change one file. That change cascades through every component, every site, every Storybook story. Nobody hunts through codebases replacing hex codes.

Stupid Simple

Here's a question: how many card variants does a university need? Block cards, list cards, overlay cards, video cards, person cards, event cards... We counted dozens. Building each one from scratch would mean duplicating accessibility logic, responsive behavior, and animation patterns. Maintaining them would be a nightmare.

Instead, we built atomic pieces that compose:

Every card variant is just a different composition of the same primitives. Add a new variant? Compose existing pieces. Fix a bug in the layout primitive? Every card that uses it gets the fix. The atomic approach turned a maintenance headache into a multiplication of capability.

Composition Over Configuration

We built tokens for websites. Then they started showing up in places we didn't plan:

Each platform consumes tokens in its native format. React imports JavaScript objects. PHP reads CSS variables. The email builder pulls from JSON. Same decisions, different implementations: exactly as Brad Frost described.

That's the payoff of treating design decisions as data rather than code: they become portable. Version them. Diff them. Roll them back. Share them across any technology stack without translation errors. The tokens package became the source of truth for the entire university's visual identity.

Tokens Travel

Brad Frost wrote something that changed how I think about design systems: the old separation of concerns (HTML for structure, CSS for presentation, JavaScript for behavior) is the wrong abstraction. The better split is between design decisions and their implementation.

A color isn't CSS. It's a decision. A spacing scale isn't pixels. It's a relationship. We built the entire token layer around this insight: capture the decision once, then let it flow everywhere: websites, apps, kiosks, Figma, wherever.

The New Separation of Concerns

How tree-shaking, modular consumption, and smart bundling keep the design system fast at any scale.

Every Kilobyte Counts

Tree shaking sounds automatic: just import what you need, and bundlers drop the rest. In practice, it's fragile. One side effect in your module, one CommonJS export, one circular dependency, and the whole bundle comes along for the ride.

The test: import one component and check the bundle. If anything else sneaks in, we've failed. This discipline means a simple landing page can use the design system and still score 100 on Lighthouse.

Designed for Tree Shaking

Not every team needs the full component library. Some need design decisions without the UI. Others need UI without the Web Component syntax. We built packages that meet teams where they are:

Each package builds on the layers below it, but you can stop at any level. A native app team using just tokens and a WordPress site using full components both get the same brand consistency—just at different depths.

Packages for Every Use Case

Performance discipline is easy to talk about and hard to maintain. A few rushed pull requests, and suddenly bundles are 50% larger. We removed willpower from the equation with automated gates.

The conversation changed. Instead of 'we should keep bundles small,' it became 'the CI won't let this merge.' Constraints beat intentions. Teams stopped proposing features that would blow the budget because they knew the pipeline would reject them.

Automated Guardrails

Here's the uncomfortable truth about design systems: most of them make sites slower. Import a component library, and suddenly you're shipping 200KB of JavaScript for a button and a card. Teams accept this tradeoff because consistency matters. But it doesn't have to be a tradeoff.

We treated performance as a constraint, not a feature. Every architectural decision got filtered through one question: what's the byte cost? Tree-shakeable exports, granular packages, CDN distribution: each choice earned its place by keeping bundles small.

The Performance Tax

How investing in shared infrastructure creates compounding value for a distributed community of adopters.

The Upstream Advantage

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.

We designed against this failure mode with aggressive automation:

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.

The Trust Problem

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

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.

Granular by Design

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.

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. The upstream investment created its own gravity.

Earning Adoption

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.

We 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.

Invest Once, Benefit Many

How SOLID principles enabled a platform-agnostic design system that works across PHP, Java, React, Vue, Angular, and static sites without forcing technology choices.

One System <br /> Any Stack

We ran accessibility audits across hundreds of sites. The patterns were clear: the same failures everywhere. Keyboard navigation broken on carousels. Focus states missing on buttons. Color contrast failing on the same brand red. Each team had independently made the same mistakes.

The technical inventory showed something else:

The insight: these weren't individual failures. They were systemic. Teams weren't bad at accessibility; they just didn't have the time or expertise to get it right. Solve the problem once, upstream, and every site benefits.

What the Audit Revealed

SOLID principles are usually taught in the context of object-oriented programming. But they're really about managing complexity at scale. We applied them at the package level:

These aren't academic concerns. They're what makes the difference between a system that becomes unmaintainable after two years and one that keeps getting better.

Why SOLID Still Matters

Think of the system as a stack. Each layer builds on the one below, but you can stop at any level:

A marketing team might use just the playground to configure components. A development team might import tokens and build their own React components on top. Both are valid. Both get the accessibility and brand consistency baked in.

The Package Stack

The hardest part of design systems isn't building components. It's getting people to use them. We removed every excuse by offering multiple paths:

The key insight: all three paths produce identical output. The marketing coordinator using the playground and the engineer importing via NPM get the exact same accessible, tested, performant component. The quality is in the system, not the consumption method.

Three Paths to Adoption

Numbers matter, but they're not the whole story. Here's what we can prove:

The less quantifiable change: departments that never talked now share a vocabulary. When everyone uses the same components, conversations shift from 'how do we build this' to 'what should it do.' That's the real win.

Proof Points

A university with 1,600+ web applications, twelve colleges, and zero shared infrastructure. Every team picks their own stack: WordPress, React, Angular, legacy Java, static HTML. Whatever solves their problem.

Building a design system for this environment means building for all of it. No 'just switch frameworks' conversations. No forcing choices. Components that work everywhere or nowhere at all.

Brand Consistency Across 1600+ Applications

One System, Any Stack

Building a fresh meal delivery startup from scratch, using smart algorithms to compete with well-funded giants.

Algorithm Driven Logistics

Counting macros is powerful but complicated. Athletes have done it for decades, but most people don't want to weigh food and do math. We built a calculator that did the hard work.

You'd tell us your goals (lose weight, build muscle, maintain) and we'd figure out your ideal protein, carbs, and fat. Then we'd match you with meals that hit those numbers.

After we launched the calculator, orders jumped. People finally understood what they were eating and why. Retention went up because customers saw real results.

The Macro Calculator

Fresh food and nationwide shipping don't mix well. Everything has to stay cold. Delays mean spoilage. And shipping costs can eat your entire margin.

We started local, within a 50-mile radius. But customers wanted us everywhere. So I built a multi-carrier system that compared rates across UPS, FedEx, USPS, and DHL in real-time.

The core was a greedy algorithm. (A 'greedy algorithm' makes the best choice at each step without looking ahead, like always taking the lowest price that meets the constraints.) It checked each carrier's rates for the specific package weight, destination, and delivery speed. Then it picked the cheapest option that got there on time and kept the food cold.

Some orders went ground. Some went overnight. Some split across carriers. The system figured it out automatically, and customers saw lower shipping costs than our competitors.

The Shipping Problem

The algorithm worked great for customers. Too great. We'd have ten orders going to ten carriers on the same day. Our fulfillment team was drowning in different packaging requirements and pickup schedules.

So I added business rules on top of the raw optimization:

The result was a system that balanced customer value with operational sanity. Shipping costs stayed competitive, but we weren't killing ourselves behind the scenes.

Balancing the Business

After a profitable first year, we made the hard call to shut down. Not because we were failing; we were still making money. But the math on growth didn't work.

We could have raised more money and joined the land grab. Instead, we exited while profitable and moved on.

The technology lived on. That shipping algorithm pattern showed up in other e-commerce projects. The rapid MVP approach became a template. The macro calculator logic evolved into other personalization tools.

Sometimes the best outcome isn't winning the war. It's learning what you can take to the next battle.

What Happened

In 2016, meal delivery was exploding. Blue Apron and HelloFresh had raised hundreds of millions. We had a small team and a simple idea: fresh meals customized to your exact macros, shipped nationwide.

As CTO, I built the entire platform in six months. Our secret weapon was a shipping algorithm that found the cheapest way to get perishable food anywhere in the country. That algorithm let us hit 20% margins while our competitors burned through VC cash.

Competing with Giants

Building API services that let thousands of university websites share news, events, and alerts automatically.

Connecting Campus Content

We broke campus content into six categories, each with its own API:

Each API has its own data model. Events need dates, locations, and categories. People need titles, departments, and research areas. We designed schemas that work across the whole university.

GraphQL lets sites request exactly what they need. A department homepage might want three featured stories and five upcoming events. A research center might want people filtered by expertise. One query, one response, no wasted data.

The Content APIs

Before, a handful of trained editors created all the content. Departments would submit requests and wait. The bottleneck was brutal.

We built tools that let anyone contribute:

Now hundreds of people create content. When big news breaks, stories go live in minutes instead of days. During major events, we can spin up dedicated landing pages with fresh content from across campus.

The central team shifted from creators to curators. They focus on quality, consistency, and the big-picture stories. Departments handle their own day-to-day content.

From Gatekeepers to Curators

Something interesting happened as more sites connected: the system got more valuable for everyone.

The design system components plugged directly into the APIs. Drop in a news feed widget, and it's already styled and pulling live content. No custom code needed.

We're now connecting hundreds more sites. Each new connection adds content to the pool and gets value from everything already there. The flywheel spins faster with each addition.

The Network Effect

The shift to API-driven content changed how campus communications work:

But the biggest change isn't in the numbers. It's in the culture. Departments that used to hoard information now share it freely. They saw that contributing to the common pool benefits everyone, including themselves.

Content sharing became the default, not the exception. That's the real transformation: technology that makes collaboration easier than isolation.

The Impact

The University of Maryland has twelve colleges, six divisions, and over fifty departments. Each runs their own websites. That's 1,500+ sites with millions of pieces of content, and no way to keep them in sync.

We built API services that changed how content flows across campus. Write a news story once, and it shows up everywhere it belongs. Post an event, and every related site gets it. Send an alert, and the whole campus knows in seconds.

One Source, Many Destinations