I’ve worked with both structured, token-driven design systems and newer, developer-first tools like ShadCN. I’ve taken this approach more than once, aligning design and code from day one with senior engineers at two different companies, so this isn’t a technical comparison. It’s what I’ve learned about how teams actually work when they’re balancing speed, quality and limited time.
None of this is a new tension. Every small team scaling past a handful of components eventually asks whether more structure is worth the overhead. What I can offer is what actually happened when I ran it twice.
The clearest win was practical: one shared set of styles between design and engineering meant a single update instead of a dozen.
Start with how the engineers already work
Before changing anything in Figma, I audited how the engineers were building and styling their CSS, then aligned those conventions with ShadCN. That mattered more than any component choice. It meant design and code started from the same place. I also wrote the documentation that went with it.
The codebase felt accessible rather than imposed. Developers could work without friction, and I could update Figma components and tokens without breaking anyone’s flow. The result was genuine alignment between design and engineering, not through meetings or handoffs, but through shared ownership.
The hard part was cultural
ShadCN gives designers flexibility, but it can also feel threatening. Because the framework is so developer-friendly, designers sometimes assume it makes their role less essential, that design decisions are being coded in before anyone has validated them visually.
The truth is the opposite. ShadCN increases the need for design leadership. Someone has to define hierarchy, accessibility, interaction standards and naming conventions. Without that direction, it turns into a collection of pretty buttons.
So the challenge isn’t technical adoption. It’s buy-in. Designers have to see it not as automation, but as a shared foundation where design and code finally speak the same language.
What traditional systems cost
Traditional design systems work best in large organisations, with many designers and engineers across many products. Shared tokens, locked-down components and formal contribution models create consistency at scale. That brings reliability and polish, and it also brings friction. Every update becomes a governance decision, and the gap between design intent and what actually gets built often widens.
In a smaller company that overhead can outweigh the benefit. With one or two designers and a handful of engineers, design ends up spending more time maintaining the process than improving the experience.
What ShadCN gives you instead
ShadCN is built for movement. It’s copy-and-own by design, so teams can adapt components, align them to the brand and evolve the system without waiting on releases or dependency updates. It isn’t a design system in the formal sense. It’s a starting point that grows into what you need, rather than something you inherit with a hundred rules you’re scared to break. It’s pragmatic and it isn’t perfect, but it’s real.
Finding the balance
The most successful teams I’ve seen treat ShadCN as a flexible base, then layer on system thinking as the product matures:
- · Start with ShadCN components to move quickly
- · Introduce tokens, spacing scales and semantic colours once patterns stabilise
- · Document what matters, not everything
- · Keep accessibility and naming consistent from the start
That way the system stays flexible but grounded. It grows with the product rather than ahead of it.
Traditional systems protect consistency. ShadCN protects momentum.
When your team is five people trying to build something that feels bigger, momentum is everything. But the reason I’d do this again isn’t a feeling, it’s the maths. Before this, a colour or spacing change meant updating it separately in Figma, in the CSS, and in however many components had drifted from both. Afterwards, it meant updating one shared source and watching it propagate. One change, not a dozen, every time.