Design Systems as the Operating System for Web Ecosystems: Takeaways from “Building Web Development Ecosystems” by Fabian Hippmann (Moonshiner GmbH)

The case for design systems in complex product portfolios

In “Building Web Development Ecosystems,” Fabian Hippmann (CTO, Moonshiner GmbH) lays out a pragmatic blueprint for scaling front‑end work across teams, stacks, and brands. The premise is familiar: without a design system, every project starts from scratch. An agency hands over a layout, and engineering rebuilds buttons, selects, steppers, and form controls—again. Before features ship, a sizable chunk of time evaporates on basic components.

Hippmann quantifies the pain succinctly: teams spend “more than, I would say, 20 to 30%” of project time just bootstrapping the base layer. Multiply that by multiple applications, brands, or teams, and you get an explosion of re‑implementations. Worse, users feel it. The same “1 of 5” stepper looks and behaves differently in each app. The analogy he uses is telling: switching between apps can feel like going from Google to Bing—you have to stop and reorient. For customer‑centric companies (think energy providers, banks, insurers), that fragmentation is a no‑go.

Hippmann’s thesis: a design system is more than a library. It’s a shared language and an extensible, testable, governed platform that connects design, engineering, and brand. Or as he puts it, “we want to focus on the features and not the pixels.” The rest of his talk explains how Moonshiner translates that principle into architecture, workflow, and tooling.

The problem space: inconsistency, duplicated effort, and missing language

• Projects reboot the same base components over and over.
• 20–30% overhead just to get to “usable” UI.
• Diverging brand and UX across apps; users relearn common flows per product.
• Designers, developers, and brand/marketing operate in silos and talk past each other.
• Poor scalability: copying code between apps leads to two systems to maintain.

Hippmann’s concrete example—the stepper—captures the essence: Teams independently design and build the same pattern n times, each a bit different. Users lose trust and efficiency. Organizations pay for every variance twice: once in build time, then in maintenance.

From one‑off projects to ecosystems

When Moonshiner engages, they begin by mapping the customer’s ecosystem: technologies in use, the people who will collaborate, how strict or loose the brand rules should be, and how easy customization needs to be. From there, they establish a single source of truth:

• A central repository for UI components, a token style guide, and a CLI, consumable via NPM.
• A style guide that shows component and code side by side—the “left/right” view Hippmann references makes joint reviews straightforward.
• A structure that supports a portfolio beyond a single app (e.g., a progressive web app plus a dealer space) without forked code or duplicated systems.

Crucially, they avoid binding the system to a single framework. In many organizations, stacks differ for valid reasons. So they decouple layers—from tokens to CSS to framework‑level components and page‑level building blocks—to meet teams where they are without sacrificing consistency.

The multi‑layered architecture

1) Design tokens: the smallest building blocks

Colors, sizes, and spacings are extracted into dedicated packages. These design tokens are technology‑agnostic and can be consumed by React, Angular, native, or desktop applications. If a team “just wants colors and spacing,” they implement the tokens and nothing else.

2) Compiled CSS and HTML blueprints

For lightweight adopters—say, a marketing landing page built by an external agency—Moonshiner provides compiled CSS plus HTML blueprints from the style guide. Import the CSS, copy the HTML structure, and the page “still looks like it’s a fully blown React, Angular or whatever application.” That keeps the surface consistent even outside app frameworks.

3) UI components vs. CMS components

Moonshiner distinguishes two consumption modes:

• UI components: the basic building blocks that must “just work”—buttons, dropdowns, forms, etc.—for application teams.
• CMS components: tech‑agnostic page modules for content (e.g., data privacy pages). The same components can render in WordPress, Gatsby, Next.js/Nuxt.js, or schema‑oriented backends. Teams don’t have to commit to Sitecore or Adobe Experience Manager syntaxes to keep a consistent look and feel.

This separation accelerates both content and app work. Content teams assemble pages with CMS components; app teams implement behavior with UI components. Both rely on the same tokens and CSS.

4) Technology flexibility, including Web Components where needed

If a company can converge on one framework, that’s “a luxury” that pays off. But where stacks vary, decoupling is key. In one case (“Signalituna”), Moonshiner opted for Web Components on the rendering layer while continuing to offer CSS and tokens from the same pipeline. That keeps adoption flexible without losing brand identity.

From pixels to features: aligning teams with a ubiquitous language

Hippmann is explicit: designers shouldn’t have to code, and developers shouldn’t have to design—but both must mean the same things with the same words. Without a shared language, handoffs devolve into “one pixel up” debates and guesswork about variants (“red button, outlined, rounded?”). The fix is a ubiquitous language expressed in tools used by both sides.

Figma as the connective tissue

Figma shines here because it embraces a developer‑friendly mental model. Variants and components let designers “think like in development.” In a “Stratum UI design kit” example, designers choose types and shapes from dropdowns—the exact parameters developers use. The result is tangible: “pages were built up in a day; the design review took half an hour and then it was done.” Fewer iterations, more flow.

Automating token sync from Figma

Figma also provides “a really world‑class, I would say, REST API.” Moonshiner uses it to synchronize base tokens directly from Figma into code, under version control. That removes a tedious weekly dance: designers tweak values, developers hunt and copy changes, both sides review manually. Automation “takes away the work from developers” and “incentivizes designers to think about their whole structure properly” because changes have a visible impact in code and can be inspected via schemas.

Governance and delivery: monorepos, workspaces, CLIs, and style guides

A design system succeeds when it’s easy to ship and upgrade. Hippmann’s delivery pattern includes:

• NPM‑consumable packages and a CLI to bootstrap projects consistently.
• A central monorepo with workspaces so related parts (tokens, CSS, UI components, CMS blocks) version together and publish cleanly.
• A style guide that shows components next to code, acting as a living test bench and a shared reference for designers and developers.

The goal is smooth onboarding, predictable versioning, and traceable changes across a multi‑app ecosystem.

Operating the ecosystem: project schemas and a developer portal

Once you run 10, 30, or 40 applications, visibility matters as much as components. Moonshiner attaches a project schema to every app—APIs used, how the front end is built, and who is responsible—and surfaces that in a developer dashboard.

Here, Hippmann recommends Backstage powered by Spotify, the open‑source internal developer platform. Backstage gives teams a unified view across front end and back end (addressing the usual split), an ecosystem of plugins, and a place for logs, documentation, and onboarding. When Moonshiner started building the “Lutz” platform (“2007” in his timeline), they already prioritized a developer platform so engineers could see their services and responsibilities clearly. Backstage now fills that role neatly, and customer teams have adopted it quickly.

Case studies: from greenfield to scaled platforms

Wien Energie

At the start of the lockdown, Moonshiner kicked off the new Wien Energie website on top of their design system. Within about half a year, four to five more applications were built on it—some by external teams. The system adapted to WordPress, a schema‑oriented CMS backend, Gatsby, plain React, and Create React App. User feedback was positive, and “applications could be done in under a day” where previously multiple iterations were needed.

X66LOOTS Group

With the internal X66LOOTS team, Moonshiner helped build the group’s e‑commerce architecture. The challenge: multiple brands (“Möbelix, Mömark, Poco”) under one umbrella but run on a single tech stack. The outcome: a React‑based foundation that one team maintains across all brands.

Signalituna

In this setting, many people and stacks were involved. Moonshiner chose a Web Components‑based design system for the front‑end rendering while still offering CSS design tokens. The emphasis was on collaboration and longevity: how teams communicate, how they build applications that last “years,” and how to grow teams around a shared base.

Across all three, the pattern repeats: start greenfield with a system, roll it out to more brands and apps, and scale developer headcount—without losing speed or consistency.

The tooling that stuck: stability over novelty

Moonshiner uses many technologies—Vue.js, Web Components, and more—but a few constants stand out:

• React and Preact as the “super powerful” view layer. They can be integrated into Angular “with a bit of twisting,” and the community and design make them safe bets for the long term.
• “ReactKit” as the accessibility library underpinning the system (e.g., at Wien Energie). Forms and state management benefit greatly; accessibility has a “really solid base,” reducing the need for retrofits.
• Yarn as the package manager of choice. Compared with Learner and NPM, the speed is “crazy, crazy good.” Workspaces and a monorepo approach are standard because the core parts “belong together.”
• Backstage as the internal developer portal to make front end and back end visible in one place, centralize logs and docs, and standardize onboarding.

Hippmann notes they’ve repeatedly questioned whether to switch tools, but these have “proved super worthy” over and over. The communities and staying power matter—especially when you need a system that will still be maintainable five years out.

Practical takeaways for engineering teams

From the DevJobs.at editorial vantage point, here are concrete actions that map directly to Hippmann’s talk:

1) Establish a ubiquitous language across design and code.

• Name and parameterize components the same way in Figma and in your component APIs.
• Use Figma variants/components so designers literally select the same options developers consume.
• Reflect those parameters in your style guide and documentation.

2) Deliberately separate system layers.

• Extract tokens for colors, spacing, and sizes into versioned packages.
• Provide compiled CSS and HTML blueprints for lightweight consumption.
• Offer UI components for interaction and logic, and CMS components for content, independent of specific CMS syntaxes.

3) Automate token synchronization.

• Use Figma’s REST API to sync foundational values into code under version control.
• Remove manual value‑copying and reduce review friction across teams.

4) Organize delivery for scale.

• Use a monorepo with workspaces for the core system.
• Publish NPM packages and provide a CLI for consistent project bootstrapping.

5) Add governance and visibility from day one.

• Attach a project schema to every app (APIs used, front‑end build, ownership).
• Stand up a developer portal (e.g., Backstage) for logs, docs, onboarding, and a unified catalog across front end and back end.

6) Choose technologies with longevity.

• Optimize for team growth, maintainability, and hiring, not novelty.
• Prefer ecosystems with deep communities and stable mental models.

7) Measure success by speed and consistency.

• Aim for outcomes like “pages in a day, review in half an hour,” which become realistic once language, tokens, components, and governance are in place.

Closing: Focus on features, not pixels

“We want to focus on the features and not the pixels.” Fabian Hippmann’s refrain captures the essence of building web development ecosystems. A design system delivers that focus technically (tokens, CSS, UI/CMS components, Web Components, monorepos), organizationally (a shared language, a living style guide), and operationally (project schemas, developer portals, Backstage).

The case studies—Wien Energie, X66LOOTS Group, and Signalituna—show how a single system can underpin multiple apps, brands, and teams. Sometimes it’s React/Preact. Sometimes it’s Web Components. Sometimes it’s WordPress or Gatsby. But the design identity and development flow remain coherent.

For teams managing a portfolio today, or launching a new one, the path is clear: decouple components, centralize tokens, tier your consumption paths, automate the flows between design and code, and make ownership visible. That’s how you build a web ecosystem that carries not just your next app, but your next several years—the standard set by “Building Web Development Ecosystems.”