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, 12 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.

Launched 2023. Over 100 sites adopted in the first year — without a mandate.

Brand Consistency Across 1600+ Applications

One System, Any Stack

A personal sports-draft prediction game that began as a graduate thesis in 2019 and has become a production-grade multi-sport platform — without a marketing budget.

Draft Slot

The original version was two repos, both dated early 2019. The API was Laravel 6 with Lighthouse GraphQL and Passport for OAuth. The frontend was React 16 with Apollo Client for data and Redux for local UI state, bundled with a hand-rolled Webpack config.

I picked every piece for a reason: GraphQL was new, Apollo was new, and picking them meant I'd learn them. That was the entire point of a thesis project.

It delivered the thesis. It did not deliver a product. I submitted the work, graduated, and the repos went quiet for almost two years.

The Thesis

When I came back to it, I didn't port the old code. I rebuilt the whole thing in a single Laravel monolith with Blade templates, Alpine.js for interactivity, and Tailwind for styling. The GraphQL layer was gone. The SPA was gone.

The choice looked unfashionable on paper. In practice, it was the only one that made sense. I had no team, no budget, no investors, and a full-time job. Every hour I spent tuning a bundler or fighting hydration was an hour I wasn't spending on features my users could actually see.

The tradeoff was real. I gave up some of the polish a proper SPA offers. What I got back was velocity. Shipping something on a Sunday night became normal again.

The Reset

The hardest part of a draft prediction game is the draft itself. On draft night, every user is watching the same board and every pick needs to reach every connected browser in seconds.

I layered the real-time system in pieces. Laravel Reverb handles WebSocket broadcasting over public channels named after the draft (draft.nfl.2026). Laravel Echo on the client subscribes. Each pick is a broadcast event. The client-side store keeps only the last 50 picks in memory — the UI doesn't need more — which keeps long drafts light on mobile.

There's an override system too. When the feed goes quiet — and it has, on several draft nights — I can upload a CSV and the scoring engine replays from there. The live experience stays intact even when the upstream doesn't.

Live Drafts, In Real Time

A side project is easy to treat like a side project. I've tried to do the opposite — you can see it in small things like the scoring panel above, polished down to the last cell. The plumbing that users never see is the plumbing that determines whether this thing survives.

Over 1,800 commits and 115 database migrations, each one small and boring. That's the shape of a codebase someone has actually lived with.

Built Like A Real Product

A draft game has a brutal traffic shape. Most of the year, nobody is here. For a few days in April, July, October, and June, everyone is. Running at peak capacity year-round would eat the budget. Running too cold would break the nights that matter.

I encoded the calendar into the deployment itself. The Vapor config has three scaling profiles — offseason, pre-draft, and draft week — and I switch between them as the season approaches:

Sponsored rooms carry some of that cost now — brands funding prize pools inside the app — but the seasonal scaling is what keeps the fixed side sane on a personal budget. It's the kind of cost optimization a small company would do for real money. For me, it's what keeps this project inside the budget of a personal side project.

Paying For The Quiet Months

Inside The App

The next chapter is two moves. First, I'm migrating the platform off Laravel Vapor and onto Laravel Cloud. Vapor has served the project well, but Cloud is built around the way Laravel apps actually run, and the ergonomics — along with the ops cost — are a better fit for where the project is headed.

Second, for the first time, I'm giving this thing a real push. Next season I'm running my first paid experiments. The goal is meaningful engagement with real users — not vanity metrics — to see what this product looks like when people actually know it exists.

The best thing about a side project is that it moves on your schedule. The scary thing about a side project is that it moves on your schedule. The work now is keeping the craft intact while finally letting more people in.

What's Next

In 2019, as a thesis for my first graduate program, I built a fantasy draft game. It was split across two repos — a Laravel 6 GraphQL API and a React 16 SPA — and when I turned it in, it worked. It also never shipped to a single real user.

Six years later, that thesis has become Draft Slot. It runs live drafts across the NFL, NBA, MLB, and NHL. It has real users, paying sponsors, and infrastructure that scales up for draft night and back down for the offseason. It's the project I keep teaching myself new things on — and the one I've never once paid to market.

Six Years, One Idea

Six Years on One Idea

Shipping an Apollo/GraphQL backbone and an internal B2B support portal on Under Armour's $1B+ commerce platform — so service agents could work in seconds instead of minutes.

Headless Commerce <br /> at B2B Scale

The commerce graph had everything — orders, inventory, customers, returns, shipments — but support tools were stitched together against legacy REST endpoints that assumed a shopper, not an agent. Latency was fine for a product page and brutal for a ticket queue.

We stood up a headless Apollo/GraphQL layer that sat in front of the commerce services and gave agents what they actually needed: a single query that pulled an order with its line items, shipment status, return history, and customer record in one round trip. The front end subscribed to live updates over Apollo, so when a shipment status changed mid-call, the agent's screen changed too.

The polyglot stack underneath — Scala services, PostgreSQL, Kubernetes, Terraform — didn't need to change. The GraphQL layer was the translation.

The Backbone

The portal itself was deliberately boring. Support teams don't want cleverness; they want the right data in the right place, and they want it now. We sat with service managers, mapped the three or four workflows that ate most of their day, and rebuilt those as single-screen flows.

The win we could measure was ticket resolution time: 35% faster, driven by fewer tab switches and fewer round trips. The win we couldn't measure was morale. Agents who'd been apologizing to customers for software stopped apologizing.

The Portal

I was at UA for eleven months. The goal was never to ship my components — it was to ship the patterns the next engineer would copy. Two things carried the most weight:

When I left, feature rollouts were faster because the next person didn't have to relitigate how a form behaves or what a modal header looks like. That's the part of the job that's invisible until you miss it.

Standards That Outlived Me

Two lessons from UA that I've carried into every role since.

Takeaways

Under Armour's B2B arm runs on a $1B+ e-commerce platform — Scala services, Kubernetes clusters, Terraform everything. When support teams needed to manage orders, process returns, and handle escalations in real time, the legacy tooling couldn't keep up. Agents were waiting on pages the business couldn't wait for.

I joined the team that fixed that: a headless, Apollo/GraphQL-powered portal that let agents do their jobs in seconds instead of minutes, and a component architecture that outlived my tenure.

When Commerce Is Too Slow For Support

Headless Commerce at B2B Scale

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 10 orders going to 10 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 12 colleges, six divisions, and over 50 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

Explore case studies showcasing Josh Magness's experience as a software engineer and UX designer

Case Studies