In this blog, I am going to explain why we moved to a mono repo 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 must set up a git repo, CI CD, access, etc. We have already seen these repetitive steps:

• New extension = new Git repo
• 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

Also, if in future, the base Sitecore Marketplace app SDK changes/upgrades? Good luck updating 5+ repos manually.

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 keeping one Git repo, 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 one we add in 5 minutes

├── template/                     ← read-only git subtree of Sitecore’s official starter

└── tsconfig.base.json            ← one source of truth for all TS settings

Key rules we enforce:

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

Benefits That Actually Matter in Production

• One deployment URL

All extension routes are served from this single deployment

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

https://xc-marketplace.vercel.app/item-publishing

Register once in the XM Cloud Marketplace portal.

• Zero duplication

Shared UI components, TypeScript config, lint rules, and the critical useMarketplaceClient hook with built-in retry/backoff.

• Isolated development & testing

Each packages/* can be type-checked, built, and unit-tested independently with npm run typecheck -w @xc/image-focal-point.

• Instant scaling

Adding a brand-new extension takes exactly three steps (see “Adding a New Extension” in the README). CI/CD requires zero changes.

• Vercel + GitHub Actions love it

One vercel.json, one GitHub workflow that runs lint + typecheck + build on every PR. Root scripts delegate to @xc/marketplace, which automatically includes every route.

Pros vs Cons 

Pros

• Dramatically lower operational overhead (one repo, one pipeline, one hosting bill).
• Consistent code quality and branding across every extension.
• Fast onboarding: new developers see the entire product in one clone.
• Easy upstream syncing via git subtree (the script even warns about SDK drift).
• Monorepo cache benefits in CI (TurboRepo-style speed even without Turborepo).

Cons (and how we mitigate them)

• Repo can grow large → We keep packages tiny and use npm workspaces + project references. VS Code still resolves everything instantly.
• One bad package can break the build → We run npm run check per workspace in CI and use isolated tsconfig.json files.
• All extensions share the same Next.js build → Acceptable trade-off because we only have 2–3 extensions live at any time and the build is < 30 seconds.
• No per-extension versioning → We version the entire monorepo together (works fine for internal + client-specific extensions).

For teams shipping 10+ extensions, the pros crush the cons.

How to Add a New Extension (Literally 5 Minutes)

1. mkdir -p packages/new-feature/src + minimal package.json + tsconfig.json (extends ../../tsconfig.base.json).
2. Add "@xc/new-feature": "*" to apps/marketplace/package.json and to transpilePackages in next.config.ts.
3. Create apps/marketplace/src/app/new-feature/page.tsx (single re-export).
4. npm install + add to root tsconfig.json references.
5. Done. CI and Vercel pick it up automatically.

If you’re an enterprise Sitecore partner or large XM Cloud customer tired of copy-pasting the same boilerplate into 5+ repos, this pattern will save you weeks of engineering time. If you need any more information, please reach out to me or contact me on Kautilya Prasad | LinkedIn