In this blog, I am going to explain why we moved to a monorepo architecture for extending Sitecore functionality using the Sitecore Marketplace starter kit. The SitecoreAI Marketplace starter kit lets developers extend the Pages editor with powerful custom panels, fields, widgets, and more—shipped as lightweight Next.js apps. But maintaining multiple extensions across separate repositories quickly becomes a maintenance overhead; this monorepo architecture changes that.

We had to create multiple Sitecore Marketplace apps for the organization. Every time we needed a new marketplace app, we had to set up a Git repository, CI/CD pipeline, access permissions, and more. These repetitive steps quickly became a bottleneck.

We repeatedly encountered the following challenges:

• New extension = new Git repository
• New extension = new Vercel project (or Netlify, etc.)
• New extension = duplicated package.json, ESLint, Prettier, Tailwind, TypeScript, and SDK boilerplate
• New extension = another deployment URL to register in the XM Cloud Portal

Additionally, if the base Sitecore Marketplace app SDK changed or required an upgrade, updating multiple repositories manually became extremely time-consuming.

At XCentium we hit this wall after the second extension. So, we built one monorepo that lets us ship as many Pages Context Panels, Custom Fields, Dashboard Widgets, or Fullscreen extensions as we want, while maintaining a single Git repository, one Vercel deployment, and one production URL.

Here’s the architecture we’re running in production today.

Repository Architecture

xc.marketplace.apps/
├── apps/
│   └── marketplace/        ← ONLY deployable Next.js app (Vercel root)
├── packages/
│   ├── ui/                 ← shared shadcn/ui + Tailwind
│   ├── core/               ← shared useMarketplaceClient hook + retry logic
│   ├── image-focal-point/  ← fully isolated extension
│   ├── item-publishing/    ← fully isolated extension
│   └── publishing-triggers/← next extension added in minutes
├── template/               ← read-only git subtree of Sitecore’s official starter
└── tsconfig.base.json      ← single source of truth for all TypeScript settings

Key rules we enforce:

• template/ is never edited directly (managed via git subtree).
• Every extension lives in its own packages/* workspace.
• The host app at apps/marketplace contains only thin route files that re-export the actual components.

Benefits That Actually Matter in Production

• One deployment URL

  All extension routes are served from a single deployment environment:

  https://xc-marketplace.vercel.app/image-focal-point
  https://xc-marketplace.vercel.app/item-publishing

  This means the deployment only needs to be registered once in the XM Cloud Marketplace portal.

• Zero duplication

  Shared UI components, TypeScript configuration, lint rules, and the critical useMarketplaceClient hook with built-in retry and backoff logic are reused across extensions.

• Isolated development and testing

  Each workspace in packages/* can be independently type-checked, built, and tested using commands like:

  npm run typecheck -w @xc/image-focal-point

• Instant scaling

  Adding a new extension requires only a few simple steps, with no CI/CD modifications required.

• Vercel and GitHub Actions integration

  A single vercel.json configuration and one GitHub workflow runs linting, type checking, and builds on every pull request.

Pros vs Cons

Pros

• Dramatically lower operational overhead (one repository, one pipeline, one hosting environment).
• Consistent code quality and branding across all extensions.
• Faster onboarding since developers can view the entire system in one repository.
• Easy upstream syncing via git subtree to keep the SDK aligned.
• Monorepo caching benefits in CI environments.

Cons (and how we mitigate them)

• Repository size may grow → mitigated using small modular packages and npm workspaces.
• One faulty package can break the build → mitigated through workspace-level CI checks.
• All extensions share the same Next.js build → acceptable trade-off due to fast build times.
• No per-extension versioning → the monorepo is versioned as a single unit.

For teams shipping ten or more extensions, the benefits significantly outweigh the drawbacks.

How to Add a New Extension (Literally 5 Minutes)

1. Create a new package directory inside packages/ with minimal package.json and tsconfig.
2. Add the workspace reference to apps/marketplace/package.json.
3. Create a route file inside apps/marketplace/src/app/new-feature/page.tsx.
4. Run npm install and update root TypeScript references.
5. Commit and push—CI and Vercel automatically pick up the new extension.

If you’re an enterprise Sitecore partner or large XM Cloud customer tired of copy-pasting the same boilerplate across multiple repositories, this architecture pattern can save significant engineering time and operational overhead.

If you need more information, feel free to reach out to me or connect on LinkedIn.

XCentium is a Sitecore Platinum Partner helping companies design, build, and optimize digital experiences with Sitecore. From strategy through implementation, we work with teams to apply AI, content, and personalization capabilities to drive measurable outcomes.

If you’re exploring how SitecoreAI can support your organization, contact our team to continue the conversation.