RazorKit is a component-driven way to build front-ends for the Umbraco CMS. You compose your UI from reusable Razor components — coded once, used everywhere — so the design system stays the single source of truth instead of drifting into copied-and-pasted markup.
Designers think in components. Most content management systems think in theme structures, content types, and template conventions. Translating between the two by hand is where consistency quietly falls apart.
This isn't a new observation. Back in 2014, Ian Feather wrote about exactly this problem at Lonely Planet: once a developer copies a component's markup, they've cut a version that has to be maintained forever — and the people who own a component rarely know everywhere it's used. RazorKit is, in large part, our answer to it. Read “A Maintainable Style Guide” →
RazorKit applies a well-established design-system methodology — atoms, molecules, organisms, popularised by Brad Frost's Atomic Design — and makes it natural to implement inside an Umbraco solution using standard Razor Class Libraries.
Build small pieces — a button, an input — and compose them into molecules, then organisms like an accordion or feature block. Code a piece once and reuse it anywhere.
View and test any component on its own — much like Storybook — but inside your Umbraco solution. Swap content, stretch the text, toggle themes, and confirm it holds up before it ships.
Components take properties, so you can drop in real copy, dummy data, or a different theme and see exactly how they respond. Useful for QA and for showing clients work in progress.
It's built on Razor Class Libraries — something .NET already supports well. RazorKit isn't a framework fighting the platform; it's a deliberate way of using what's already there.
Open one folder and you have everything for that component, with confidence you won't break anything else. Less to hold in your head means calmer, faster day-to-day work.
Because every build follows the same structure, knowledge and components transfer between projects and people. Onboard developers quickly; reuse what you've already proven.
Breast Cancer Now's website runs on RazorKit — over a hundred components, from atoms like buttons and checkboxes up to full page heroes, each browsable in isolation with editable props, component code, and built-in accessibility testing. It's a real design system serving a real audience, and it's open for you to explore.
Why not just go fully headless? You can — but it costs you two applications and a more complex hosting setup. RazorKit keeps one simple Umbraco application while still decoupling the design system from the CMS.
The theme system drives structure. Simple to host, but the design system is held hostage by the platform's conventions.
One monolithic app, simple to run — but the design system is built in isolation from the CMS layer. Separation of concerns without distributed-systems overhead.
Backend-agnostic and flexible, but two applications, more moving parts, and a heavier hosting and maintenance burden.
RazorKit grew out of real agency needs, where the cost of inconsistency is multiplied across many clients. But the approach pays off well beyond that.
Building multiple Umbraco or .NET sites and wanting consistency, faster onboarding, and reuse across projects rather than reinventing components each time.
Maintaining even a single website who'd rather work from a design-system-led workflow than be led by the CMS's structure.
Likely to build several applications who'd benefit from a shared pattern library sitting behind all of them.
The ideas RazorKit builds on — component-driven development, maintainable design systems, and the trade-offs worth weighing as an architect.
Take a look at RazorKit on GitHub, give it a star, and try it on your next build. It's open and yours to extend — if it's missing something, contributions are welcome.
Licensed under MIT — genuinely given away, with no strings on ownership.