The hard truth about enterprise design systems

Why DIY systems fail, and what to do instead

By Jesse Anton, CEO & Co-Founder of Whitespace

First published: 31 October 2025

Last updated: 30 September 2026

As AI transforms how we design and build software, design systems are undergoing a renaissance.

Consistency, reuse, and fewer repetitive design decisions are all valuable pursuits that drive in-house teams to build their own design systems. The hard truth is that all too often, these systems start strong and then quietly collapse under their own weight.

What's more, most DIY systems are not primed for agentic coding and MCP-powered workflows, leaving them vulnerable to obsolescence.

We’ve seen it happen in enterprises across various industries: well-intentioned, home-grown systems that accumulate design and technical debt — and ultimately fail.

Here’s why — and what to do instead.

The DIY trap

The scene:
A large traditional enterprise with ambitious AI-driven productivity goals bumping up against a culture that's anything but digital-native.

The plot tension:
Leadership wants to move fast and impress the Board with shiny AI objects while simultaneously cutting costs. A design system would help. But there's no design system. Or there was one, but nobody knows where it is anymore because the team that built it left to join Google. Or there are several design systems ... but it turns out they are essentially useless and gathering dust. Who will save the day?

The protagonists:
A dashing designer and daring developer come together to start a fresh new DIY design system project. It starts small. A Figma library. A few color tokens. Some code snippets. A bit of documentation in Confluence.

The build-up:
For a while, things are good. The system grows. Everyone feels aligned. Our protagonists feel like heroes. Will they live happily ever after?

The plot twist:
A blue-chip management consultancy is hired and begins working on top-secret 'disruptive' PowerPoint slides in a dark corner of the building. They have the ear of the executive committee. Nobody knows for sure, but they might be recycling last week's work for another client and using AI to 'adjust the tone and context'. A new CTO (formerly with the management consultancy) parachutes in and announces a comprehensive refactoring and overhaul of the tech stack.

The dénouement:
Cracks begin to appear in the now-doomed system, including duplicated components, mismatched patterns, and missing documentation. The users start complaining and demanding retribution. The system becomes harder to maintain — and the promise of speed turns into a drag on momentum. Funding is lost. The system is jettisoned.

The anti-climax:
Our heroes apply for jobs at Uber. The management consultancy moves on to the next victim client. The curtain falls.

The moral:
Most design systems don’t fail because they’re bad ideas. They fail because they don't have the right conditions in which to thrive.

Why failure happens

Internal design systems lack the necessary structure, skill, and stakeholder commitment to succeed. This is not a reflection on the latent talent within the organization. It reflects how the organization operates. It's cultural.

Common patterns we see:

No governance: departmental resources 'on loan' are not centrally accountable
No in-house expertise: designers lack sufficient knowledge of front-end code; development is outsourced and incentivized to build from scratch to increase billable hours
No design-to-code parity: what’s in Figma doesn’t match what's in code, with designers and developers 'detaching' from the system at will
No flexibility: product teams lack the freedom to use different JS frameworks
No data: metrics and KPIs are not available
No storytelling: the ROI is not clear to stakeholders
No funding: if nobody 'owns' it, the product dies on the vine

Without clarity and care, even the best systems turn messy. And the costs start to compound.

The result?

A fragile system: Multiple Figma files, naming conflicts, spacing inconsistencies — it all adds up when there is no process to govern the product. Every change becomes harder to trace, and risks begin to accumulate.
A system that costs more than it's worth: Intended to boost speed and save money, your DIY system ultimately erodes trust and efficiency while consuming precious time and resources. Developers doubt components, designers duplicate work, no one maintains the documentation (or the documentation is spread across too many tools for one team to maintain), and the system becomes a drain on delivery.

The highest cost? What you could be doing instead. Every dollar spent maintaining an unscalable system is a dollar not spent improving the actual products and business tools that the system is meant to support.

The problem is worse than it appears

We observe that most of our enterprise customers are being taken advantage of by their so-called 'strategic' development partners (big-box offshore IT services companies), who happily reinvent the wheel each time they assign a development team to build a new bespoke solution for the client.

Often, these partners are unaware that a design system even exists within enterprise accounts, let alone where to find a basic pattern library. They start from scratch, using off-the-shelf libraries like MUI and 'bending and twisting' them to match the client's brand identity. The same UI components are created repeatedly because every product is essentially treated as an independent 'project' that is built in silos by separate 'teams' — not 'empowered teams' in the SVPG sense, but rather more like 'mercenaries' working on the clock.

It's not entirely the partners' fault. As previously mentioned, we also observe that most of our clients struggle to establish an in-house design system that is adequately staffed, properly architected, and sufficiently evangelized. Design system resources are 'borrowed' from other departments and disappear when politics intervene and power centers shift. Initiatives are often launched but fail to deliver before leadership priorities change, funding is cut, or a reorg wreaks havoc. The momentum dies, and so does the design system.

At least for a while. Different parts of the company eventually spin up competing systems, 'skunkworks' style. There is a 'Wild West', shadow-IT mindset that pervades the product culture.

In the best-case scenarios, the design systems that do cross the chasm in enterprise environments are often challenging for both designers and developers to consume. Not to mention AI, which exposes fault lines in these systems that human processes have masked for years. As a result, adoption never reaches critical mass.

What good systems need

A scalable design system isn’t just a Figma library or a code repo that you download off the internet and 'tweak' — it’s a fully-fledged product. It requires:

1-1 mapping between design and code (or code-native design tooling)
Robust, multi-tiered design token structure
Automated CI/CD pipelines
Flexibility for a changing technology landscape
Accessibility and security by default
Instrumentation for analytics and reporting
Clear, AI-friendly documentation and guidelines (contracts, schemas...)
MCP-powered agentic workflows
A skilled and dedicated team of design and development experts to govern it

Above all, it requires trust. And trust has to be earned. This doesn't happen overnight, which is why committed stakeholders and sufficient long-term funding are necessary to bridge the gap until trust can be established and ROI proved.

What you can do about this

Which brings us back to the original dilemma. The conditions for design system success rarely exist within a large enterprise. Digital-native companies can make design systems work, but even for them, it's a significant challenge. Outside of the tech industry, the rest of the world is still struggling to cross the chasm.

So what should enterprise technology leaders do? We believe we have the answer.

Consider your design system a product that you buy, not one that you build. It's ironic to say that, because a design system exists so that you can build products.

Having built numerous design systems for various organizations, we realized we could create one that is flexible, customizable, and future-proof enough to meet the needs of the most demanding enterprise clients. Our white-label solution delivers the full value of design systems to enterprise customers, without the hassle and headaches of a DIY approach.

Introducing Edelweiss

At Whitespace, we have developed an agentic UI platform called Edelweiss™ that changes how product teams build software with AI.

Edelweiss is a turnkey 'UI infrastructure' solution for your enterprise AI architecture. Teams building software products on top of LLMs, data lakes, data virtualization, etc. — all that investment in AI-driven product development that large companies will be making over the next decade — now have a structured UI layer to tap into, meaning product builds become significantly more efficient, consistent, automated, and accessible.

Backed by an enterprise SLA, Edelweiss comes with customer success and support services that guarantee rapid returns and long-term value. Our experts stay up-to-date with the latest technology and tooling capabilities, so you don't have to. Right out of the gate, you need fewer internal resources allocated to core design system work, which means your designers and developers can stay focused on solving business problems, not reinventing the button.

We believe this is category-defining: an Agentic UI Platform-as-a-Service.

But the story doesn't end there. When AI and design systems meet, magic happens.

Set yourself up for success

AI is changing how software is designed and developed.

While vibe coding solutions, such as Lovable and V0, are interesting for ideation and rapid prototyping, they have no place in an enterprise's production software infrastructure.

Agentic coding assistants — such as Claude Code, GitHub Copilot, and Codex — are an entirely different story. They have real utility in your SDLC, provided they are given the context and guardrails in which to operate. Agentic workflows built on orchestration frameworks like n8n, and on-demand context-aware experiences facilitated by MCP Apps and A2UI, are further reasons to invest in AI-native UI infrastructure.

Edelweiss is the missing UI piece of the new agentic software ecosystem.

Context is king

Edelweiss is a platform comprising Harmony, Tuner, Composer, and Figaro. Everything is integrated and seamless. You want to build compliant, enterprise-grade products with AI assistance. We provide the UI infrastructure that makes this so much easier.

Code

For code, there's Harmony — customizable, branded libraries in both Web Components and React, ensuring that development teams are not locked into any particular framework. Great for SPAs, Web Components are portable and usable straight away on any platform and across your existing tech stacks. Our React library is for customers who have standardized on this framework or who need SSR capability. These libraries are maintained in parallel by our expert team and are evolving as quickly as different customer and industry use cases emerge.

Tokens & CSS

Tokens, CSS, and schemas are managed in Tuner, which also enables teams to manage multiple design systems built upon the Harmony foundation. Tuner is the most powerful tool on the market for generating and governing design systems. Tuner contains the logic and rules for ensuring your design systems are harmonious (see above, Harmony), accessible, on-brand, and easy to manage. The engine underlying Tuner is patent-pending.

Documentation

AI works best with structured documentation, and ours is complete and precise. Each component is fully documented in Storybook and JSDoc. We also provide an editable, centralized documentation repository in Tuner for specifying usage guidelines and generating well-formed schemas for AI to consume as opinionated design context at build time. AI can access guidelines and component props via Harmony MCP.

Design

Composer is an agentic and collaborative tool for product teams building brand-compliant, accessible front-ends with AI. Designers and developers work together in a design-with-code environment to craft patterns, templates, and connected screen flows that generate working prototypes and production-ready code. Patterns, flows, and screens can be shared across products and design systems. Everything is canvas-based and multi-user, like Figma, except the medium is real code on the canvas, not pictures of what the interface should look like.

Gone are the days of fumbling with Figma mocks, clunky Figma plugins, Figma MCP, and endless handover meetings to convey design intent to developers. Instead, designers can test earlier and more frequently with stakeholders and deliver artifacts that developers can use in production. For their part, frontend developers can now spend more time on backend integration tasks (e.g., hooking up to GraphQL or REST endpoints) and less time on interpreting 'fuzzy' design directions.

AI assistance

Both Composer and Tuner are powered by Figaro, our built-in AI assistant and vibe design agent, saving you time and effort as you deliver compliant, accessible, production-ready designs. Figaro makes a product team’s job easier:

You want to use Composer to vibe design a solution to a problem. Figaro gives you three options to choose from and uses fully compliant and tuned Harmony components to do it.
You want to connect pages into a flow or add more cards to a composition. Figaro makes the changes for you.
You want to darken the primary brand color across all design systems. Figaro traces every token that references “brand primary” and shows you the full impact before you commit.
You want to make sure your complex interaction specs are complete. Figaro checks for missing states, failure modes, contradictions, accessibility, and usability best practices.

MCP

AI agents can invoke Harmony-based design systems via MCP. The Harmony MCP Server enables product teams to ‘tame’ agentic coding assistants, ensuring they only use the coded components from the design system library. Effectively, agents will no longer pull from code found in the wild while you 'hope for the best' (aka 'prompt and pray'). Unlike tools such as Lovable or Claude Design, you get near-deterministic output whether you use Composer or go directly through an agentic assistant like Claude Code or Codex.

More bang for your buck

Code reuse is a big deal. Branded, accessible, and AI-ready code reuse is an even bigger deal.

We expect Edelweiss to save enterprise clients millions every year, not only on in-house DevOps and DesignOps costs, but also on product development and brand management costs.

Procurement can use it as leverage to renegotiate contracts with the 'strategic' development partners mentioned above.
Product teams can put working prototypes in front of business stakeholders more frequently, which reduces risk and shortens time to value.
Marketing and Brand teams can manage multi-brand ecosystems and global design updates from a single source of truth instead of 'policing brand compliance' ad hoc.
IT leaders can accelerate delivery in both agentic and traditional coding environments, while improving consistency, quality, and accessibility.

This solution delivers clear ROI. And this is just the beginning of our journey. HTML presentations are on the roadmap. Hello PowerPoint and Google Slides, you've got competition!

Interested in the private beta? We have already signed up several multinational companies — brands you're familiar with — as early adopters. Will you join us?

You can learn more at Edelweiss.build (private beta starting in 2H 2026). In the meantime, if you are interested in becoming an early adopter, get in touch with us to arrange a demo.