0build is a full-fledged, opinionated, and highly customizable frontend design system. Born from real-world necessity, we built it on top of what’s already out there. No overengineering, no hype, and definitely no reinventing the wheel. Foundational approaches that worked a decade ago and will still work a decade from now.
Includes a large collection of commonly used components designed to look great on their own and work seamlessly together:
Built on a powerful combination of shadcn/ui and coss/ui. Your app is guaranteed to look modern and polished right out of the box, without the usual configuration complexity.
Components that naturally fit together across different frameworks, as if they were made for one another. We take their best parts, strip out the bad, and stitch them together.
Need to make a change? Simple overrides make it effortless. Your browser's devtools are your best friend, so there is no need to rebuild your entire app from scratch.
Clean Markdown documentation is provided for every component, making it easy to feed directly to your LLM companion for instant context and coding assistance.
Here, plain CSS and semantic classes come first (e.g., .z-card or .z-button-primary). Write them in a stylesheet the normal way.
Utilities are here as an escape hatch and helper, useful for a one-off spacing tweak or a fast prototype, not as the default way to build a page. We include them because the frontend landscape has moved toward utility-first workflows, and pretending otherwise doesn’t help anyone ship.
The reality is that AI-assisted coding has made development dramatically cheaper and faster than it was a decade ago. Use vanilla CSS on top of the existing design API, so the framework works for you instead of getting in your way.
The Golden Rule
Reach for plain CSS when a named class is the clearer choice. Reach for utilities when speed or a genuinely one-off case matters more than pristine clarity.
Here, we make extensive use of CSS layers:
@layer theme, base, components, styles, utilities;Component and named classes belong in the lower layers. Keep them intentionally weak so they can be overridden naturally by value-driven styles (@layer styles) and utility classes (@layer utilities). They’re always within reach when you need them.
Putting components or named classes in the highest layer—or outside the layer system—makes them difficult to override. This often leads to increasingly specific selectors, !important, and unnecessary workarounds. Keep them lower in the hierarchy and let the cascade work for you.
@layer components {
.checkout-summary {
}
}<!-- sm:m and display-flex classes are provided for you. -->
<aside class="checkout-summary sm:p display-flex" style="--sm-p: 4;">...</aside>Use unlayered styles—the highest level of the cascade—only as a last resort when customizing third-party libraries whose CSS you don’t control, such as ApexCharts.