Something I've been doing a lot throughout my career
I've spent a significant part of my career helping customers define component libraries, working through spreadsheets, Figma files, Sitecore templates, and the "we only need 30 components for phase one" conversations that inevitably become 90.
It's one of those areas that looks simple from the outside and gets complicated fast. And the thing I find interesting is that no matter how much the platform changes, the core problems stay the same.
I've seen it in Sitecore XM/XP. I've seen it in JSS. I'm seeing it now in SitecoreAI (XM Cloud). The hero banner built for brand A gets tweaked for brand B. That tweak becomes a variant. The variant becomes a fork. The fork becomes an orphan that nobody maintains. Two years later the component catalogue has tripled and nobody can tell you which version of the card component is "the real one."
What changes with each platform generation is what tools you have to prevent that. And in the SitecoreAI era, those tools are genuinely better, but only if you understand the full picture. So let me share what that looks like from where I'm standing.
How it started: the XP era and the multisite promise
In the Sitecore XM/XP world, the component library lived inside the Sitecore solution itself. Your rendering items, datasource templates, and presentation logic were tightly coupled. Reusability was a Sitecore tree problem. You modelled your templates carefully, leaned on base templates, built a shared rendering items structure, and if you were disciplined, that structure survived across multiple sites.
The website factory concept was already relevant back then. I worked with customers running multi-brand, multi-country digital ecosystems on a single Sitecore instance. The pitch was compelling: build once, deploy to twenty sites. The reality was messier. Governance was the discipline that separated success from chaos. Who owns the library? Who approves a new variant versus extending an existing component? What happens when a component drifts so far from the original design that it should really be retired?
Without solid answers to those questions, the component library became a component catalogue. And catalogues, as I've come to say, tend toward entropy.
The headless shift split the library in two
When the industry moved toward headless, and for Sitecore that meant JSS, something structurally important changed: the component library split into two separate layers.
On one side you had the Sitecore layer: templates, datasource items, rendering items, placeholder settings. The definition of what a component is, what data it accepts, where it can be placed. On the other side you had the frontend layer: React components, styled-components or Tailwind, Storybook stories, sometimes npm packages if you were ambitious enough to go that far.
JSS gave us component-builder and a registration mechanism, but it didn't solve the governance problem. It just moved part of the library definition into JavaScript. The discipline still had to come from the team.
What headless did open up, though, was a proper design system conversation. For the first time, you could point at a React component library with Storybook documentation and say: this is the source of truth for what this component looks like. The Sitecore side became the data contract. The frontend became the rendering contract. When you treated both as explicit, versioned contracts, projects went significantly better.
Then Figma changed the design conversation
I want to spend a moment on design systems specifically, because the Figma-first workflow changed how I approach these conversations with customers.
Before teams were using Figma seriously (and I mean seriously, with components, variants, tokens, and documentation, not just artboards), there was always a translation layer between design and development that introduced drift. A designer produced mockups. A developer interpreted them. Six months later the live site roughly resembled the designs but had diverged in dozens of small ways that collectively added up to a lot.
Figma's component model, combined with proper tokenisation for spacing, typography, and color, gave design systems a shared language that both designers and developers can refer to. When a customer comes to me now with a Figma library where variants are defined, tokens are named, and component states are documented, the development conversation is fundamentally different. You're translating a specification, not interpreting a feeling.
In the Sitecore context this matters because Figma components can and should map directly to components. The variant logic in Figma (card with image left vs. image right) maps to a rendering variant in XM Cloud. When that mapping is explicit and documented, authors get a coherent experience because what they see in the design matches what they find in the Pages editor.
When it's implicit, you end up with seventeen card variations in XM Cloud that don't correspond to anything in the Figma file, because developers made local decisions at build time that nobody ever documented.
Modern frontend engineering added a new layer of complexity
Over the last few years the frontend engineering conversation around component libraries got a lot more sophisticated. Mono-repos, workspaces, module federation, micro-frontends, micro-experiences, packages, versioning, Artifactory. Concepts that used to belong to backend platform teams started appearing in frontend architecture discussions.
This didn't happen by accident. It happened because frontend applications grew in scale and complexity to the point where the same organisational problems that backend teams had been solving for years started showing up on the frontend side. How do you share code across multiple applications without copying and pasting? How do you manage independent release cycles for shared components? How do you prevent one team's change from breaking another team's deployment?
Let me go through the main patterns and where they fit.
Mono-repos and workspaces (Turborepo, Nx, npm/yarn workspaces) are the answer when you have multiple applications that genuinely share code. Instead of publishing a versioned npm package for every change, you co-locate the library and the consuming applications in a single repository. Changes to shared components propagate immediately. The dependency graph is explicit. Build pipelines only rebuild what actually changed.
For customers running multiple brand sites on XM Cloud, this is a practical architecture. One packages/ui workspace with the shared component library. Each site application in apps/brand-a, apps/brand-b consuming from it. A change to the Button component goes into one PR and propagates to all sites on next build. No publishing ceremony.
Module federation (Webpack 5, with growing Next.js support) goes further. It enables runtime-level sharing of components across independently deployed applications. You ship a new version of a shared component to a federated remote, and all consuming hosts pick it up without a full redeploy.
That's powerful for organisations with complex release governance where a shared component update shouldn't require a full site redeployment. The tradeoff is operational complexity: shared state, strict versioning contracts between host and remote, and debugging across a federation boundary is genuinely painful when things go wrong. It's a tool for a specific problem, not a default recommendation.
Micro-frontends and micro-experiences operate at a coarser granularity. Instead of sharing individual components, you're composing discrete application fragments. A product configurator widget embedded in an editorial content page. A checkout snippet that lives in a separate deployment unit. These integrate at page composition level, not at component level.
In the SitecoreAI context this is architecturally interesting because the composable nature of the platform invites this kind of decomposition. XM Cloud handles editorial content and layout. A product micro-experience, potentially delivered via module federation from a commerce team, handles transactional interaction. The boundary between them is a placeholder or a rendering host.
The risk is visual coherence, when every team owns a micro-frontend with its own interpretation of the design system, the UI can fragment quickly. Governance is again what separates a well executed micro-frontend architecture from a UI that looks like it was assembled from parts of three different applications.
Versioning and the package lifecycle problem
If you're publishing shared components as packages (to npm, GitHub Packages, a private Artifactory instance, whatever), you take on the versioning problem.
Semantic versioning sounds clean until you have fifteen consuming applications at different major versions of the same package, and a critical fix turns out to be a breaking change for three of them. The standard practices apply: strict semver discipline, alpha and beta channels for pre-release validation, automated release pipelines so version bumps and changelogs aren't manual.
The thing I've learnt from real implementations is that the consuming teams need as much governance attention as the library team. If applications stay on old major versions because "the upgrade isn't in scope this sprint," the library drifts away from the consumers, you end up maintaining two generations simultaneously, and that is expensive in ways that aren't always visible until you're deep in it.
In the Sitecore specific case, there's an extra dimension: the component package version and the XM Cloud datasource template version need to stay coordinated. If you publish a major version of a component that adds a required rendering parameter, and the consuming XM Cloud site hasn't been updated to include that parameter definition, you get a runtime failure in the authoring environment. That's not a great experience for anyone. The packaging lifecycle and the Sitecore delivery lifecycle have to be managed together.
What actually changes with SitecoreAI
The Content SDK introduced something that genuinely helps here. The explicit component-map.ts means you can't accidentally have a component registered in Sitecore but absent from the frontend rendering pipeline. The failure is at build time, not at runtime in front of a content author. That's a step in the right direction and it's something I covered in more detail in my Content SDK migration post.
But the more significant shift for component libraries in SitecoreAI is really about omnichannel delivery. When I'm working with customers now, the component library conversation doesn't stop at the web channel. The same content, going through the same Experience Edge GraphQL API, needs to reach web, mobile apps, digital signage, email, and increasingly AI-driven interfaces via the Agent API.
That changes the fundamental philosophy.
In a web only world, a component is a rendering unit. It has visual properties, layout behaviour, responsive states. You design it, build it, style it. Done.
In an omnichannel world, a component is a content structure with multiple rendering expressions. The structure (fields, relationships, semantic meaning) is the stable part. The rendering is channel-specific.
When you design your component library with this model in mind, the design system conversation expands. You're not just designing visual components in Figma for the web. You're designing content models with multiple rendering expressions. The Figma component is the web expression. The mobile team has their own expression. The email template system has another. What they all share is the datasource template structure and the field semantics.
This means component library governance becomes content model governance. That's a broader discipline than most frontend teams are set up for by default.
The website factory model in the SitecoreAI era
The website factory approach is where all of this comes together. I've been applying this model with customers for years, and it's the framing I use most when a customer is operating at multi-brand or multi-market scale.
The premise is simple: instead of building a website, you're building a capability. A configurable, extensible component library and content model that can be instantiated across multiple brand sites, regional markets, or product lines with controlled variation.
In the XP era, this was a Sitecore multisite implementation with shared templates and a site-specific presentation layer. In the headless era, it became a shared component package consumed by multiple Next.js applications, with XM Cloud sites behind a shared Experience Edge endpoint.
In SitecoreAI, the website factory gains additional layers that didn't exist before:
- Shared component library via mono-repo workspaces or versioned packages, as described above
- Shared content model via XM Cloud shared items and a consistent Experience Edge schema across all sites
- Shared design tokens via a Figma library synchronised into CSS custom properties or a token build pipeline that feeds all consuming applications
My honest take on the tradeoffs
Mono-repos are only as good as your investment in them. If your CI/CD pipeline doesn't understand the dependency graph (and without Turborepo or Nx, it probably won't), you'll either rebuild everything on every commit or miss builds that should have triggered. Get the tooling right before you commit to the architecture.
Module federation is operationally fragile in ways that aren't obvious until something goes wrong in production. Version mismatches between host and remote produce runtime errors that are genuinely painful to diagnose. You need strong contract testing and clear ownership boundaries. Without those, it's a source of incidents, not a source of agility.
Omnichannel content models require investment in information architecture upfront. If you design your content model for web and try to retrofit mobile later, you'll hit structural limitations. Field names and structures that made sense for a web rendering often don't translate cleanly to a mobile native experience. Starting from the content model rather than the visual component requires a mindset shift that design and development teams don't always embrace willingly, especially early in a project.
The website factory only pays off at scale. For two sites, the infrastructure overhead probably isn't worth it. For ten or more, it almost certainly is. The inflection point depends on how similar the sites need to be. The more variation you accommodate, the more configuration surface the factory requires, and the more governance it demands.
On the SitecoreAI authoring experience specifically: whatever component library decisions you make, design with the Pages Builder in mind. Components that have clear rendering parameters, sensible default states, and good preview behaviour in Design Studio serve authors well. Components optimised purely for developer ergonomics, with opaque configurations or rendering that only makes sense in a fully composed page, create authoring friction that eventually becomes a business problem.
A few things I'd recommend to any team starting this work
Define the content model before the component. Work with architects and content strategists to identify the stable data structures first. The visual design follows from that.
Establish governance before code. Who approves new components? Who approves variants? What's the deprecation process? Document it and enforce it. A component library without governance is a component catalogue in waiting, and I've already described where catalogues end up.
Take Figma seriously. Tokens, components, variants, states, documentation. If the Figma file is a collection of artboards with no component hierarchy, it's a visual reference, not a design system. The two are genuinely different things.
Match the sharing architecture to your scale. Mono-repo for most cases. Module federation only when independent deployment of shared components is a hard requirement. Versioned packages when consuming teams have no coordination possible.
Design for omnichannel from day one. Even if you're only delivering web in phase one, make the content model channel-agnostic from the start. Field names that bake in web assumptions become migration problems when mobile or AI delivery arrives.
And if you're operating at website factory scale: invest in the infrastructure. Shared design tokens, shared content model governance, shared AI configurations. The upfront investment is real. So is the payoff when you're delivering a new brand site in weeks instead of months.
