Design Systems at Scale: Build, Buy, or Both

Most SME owners discover they have a design system problem the same way. A second product team ships a button that looks nothing like the first. A rebrand takes four months because tokens live in no one place. A new engineer spends two weeks reverse-engineering spacing rules that were never written down. The question is not whether you need a design system at scale. The question is whether building one is worth the money compared to buying something that already exists.

I will give you the honest numbers, the trade-offs I have actually seen, and the conditions under which each path makes sense.

What you are really paying for when you build

Building a production design system from scratch costs more than most founders expect, and less than most agencies quote. The work breaks into three phases: token architecture, component library, and documentation infrastructure.

Token architecture is the foundation. The industry standard in 2026 is a three-tier model: global tokens for raw values, semantic tokens for intent, and component-specific tokens for overrides. Tools like Style Dictionary v4 and Figma Variables now support the W3C Design Tokens Community Group specification natively, which means a token defined once in Figma can be translated to CSS custom properties, iOS Swift, and Android Compose without manual duplication. That interoperability has real value if you ship across platforms. If you ship one web app, it is overkill.

Component library work is where the hours stack up. A minimal viable library, covering typography, colour, spacing, form elements, and a handful of layout primitives, takes roughly four to six weeks for one senior engineer working alongside one designer. That assumes atomic design discipline: base atoms first, then molecules, then organisms. Skipping the atoms to build organisms faster is the most common mistake. You pay for it when you try to theme the system later.

Documentation is the part that gets cut and the part that determines whether the system survives past its first team. Storybook with Chromatic visual regression testing is the standard setup. Chromatic catches unintended visual changes before they reach production. Without it, a component update that looks fine in isolation can break twelve surfaces simultaneously. The Production Design System I built held to best achievable Core Web Vitals scores precisely because performance budgets were enforced at the component level, not applied as an afterthought during a lighthouse audit.

What you are really getting when you buy

Off-the-shelf systems, Radix UI, shadcn/ui, Material Design, Ant Design, give you a working component library in a day. That is genuinely valuable. The trade-off is that you own the customisation debt, not the core.

When your brand evolves, you are patching over someone else's token structure. When an accessibility requirement changes, you are waiting on an upstream maintainer. Following the European Accessibility Act enforcement deadline in June 2025, enterprise teams have been rebuilding accessibility into CI/CD pipelines as a first-class concern. A bought system may not embed WCAG 2.2 auditing the way your deployment pipeline requires. You can add it, but you are adding it to a codebase you did not design.

The hidden cost of buying is the integration tax. Mapping a third-party system's tokens to your brand tokens, writing the adapter layer, training your team on the upstream component API, and managing version upgrades across your stack can consume more engineering hours than a focused build would have taken. That is not always true. For a small team shipping a single product, buying and extending is often the right call. The calculus changes when you have multiple products, multiple brands, or a multi-market audience.

The federated model changes the build cost equation

The old argument against building was maintenance overhead. One central team owns the system, every product team waits on them for new components, and the bottleneck kills velocity. That model is largely gone. Scaling organisations now run federated hub-and-spoke structures, where product teams contribute components back to the core system through automated validation pipelines. The core team sets standards and reviews. The product teams ship.

This matters for SMEs because it means the upfront build does not have to carry the full long-term maintenance burden. If you build the token layer and the contribution workflow correctly from the start, the system scales with your team rather than against it. AI agents are now used on larger systems to automate documentation updates and flag visual regressions, which further reduces the maintenance tax on the core team.

For framework choice, the move toward framework-agnostic Web Components built with Lit means a component built once can run in a React app today and a Vue app next year without a rewrite. That is relevant if your stack is likely to evolve, which it usually is in a growing startup.

The numbers that actually matter for the decision

Here is a rough cost model based on what I have seen in practice.

Build from scratch:

• —Token architecture and Figma setup: 1 to 2 weeks, one senior engineer plus one designer
• —Core component library (30 to 50 components): 6 to 10 weeks, same pair
• —Storybook documentation and Chromatic integration: 1 to 2 weeks
• —Total: 8 to 14 weeks of senior engineering time

Buy and extend:

• —Library selection, integration, and brand mapping: 1 to 3 weeks
• —Custom component additions not covered by the library: 2 to 6 weeks
• —Ongoing upgrade and adaptation work: ongoing, typically 20 to 30 percent of initial build time per year
• —Total first-year cost: often comparable to a focused build, with less control

The break-even point for building is roughly two products sharing the same system. At one product, buying is usually faster. At two or more, the shared token layer and consistent component API pay for themselves within the first year.

The Financial Services Platform case is instructive here. Financial interfaces carry strict brand and compliance requirements that no off-the-shelf system ships ready to meet. The response time improvements came partly from components that were performance-budgeted from the start, not retrofitted. Buying would have meant retrofitting.

The conditions that should push you toward building

Build when your brand is a competitive differentiator and visual consistency is part of the product promise. Build when you operate across platforms and the token translation cost of a third-party system exceeds the build cost. Build when you anticipate a rebrand or white-label requirement within two years. Build when your team needs to own the accessibility audit pipeline rather than depend on an upstream maintainer.

Buy and extend when you are pre-revenue or pre-series A and speed to market outweighs long-term control. Buy when your product is a single web application with a stable brand. Buy when your engineering team is small and cannot sustain a contribution workflow.

The hybrid path, buying a headless component library for behaviour and building your own token layer on top, is increasingly viable and often the most pragmatic choice for a growing SME. You get the accessibility and interaction logic maintained by a larger community. You keep full control of your visual identity and token structure.

If you are at the point where this decision is real and the numbers need to be applied to your specific stack and team size, the engagement models lay out how I work through exactly this kind of scoping with founders and engineering leads.