First let me set the stage. We created an accelerator to build headless sites with an XM Cloud backend. This began as a branch from the Sitecore JavaScript Rendering SDK. Over time we added functionality that we believed would be reusable across multiple implementations.

Initially we planned to use Vercel for hosting, but requirements quickly varied across projects. Some sites required blogs or news functionality while others required integrations such as Sitecore Search, Algolia, or Coveo. To accommodate this flexibility we created modular packages so clients could install only the features they needed.
 

Different Hosts for Different Needs

As implementations expanded, hosting requirements began to vary. Some clients preferred Netlify while others continued with Vercel. To support both environments we modified the middleware from Sitecore’s example implementation so hosting configuration could be controlled through environment variables.

Rendering hosts also needed to support multiple environments. We updated the XMCloud.build.json configuration to define multiple rendering hosts for production and internal environments.
 

Multi-Site and Layout Considerations

Another requirement emerged when a client needed a multi-site setup running from a single code base. The components were shared between sites, but the layouts and styling needed to differ depending on the site context.

To support this requirement we introduced conditional layout rendering in the Layout.tsx file.
 

When the Tooling Changed

Later, new updates in the Sitecore example repository introduced the use of PNPM instead of Yarn for package management. While this simplified build scripts, it exposed a number of assumptions we had built into our accelerator.

Yarn had previously been tolerant of loosely defined internal package references. PNPM was far stricter, which meant portions of our existing setup needed remediation.
 

What We Learned

Over time we realized we had diverged significantly from the original Sitecore example repository. Each new enhancement introduced additional complexity, making it harder to incorporate upstream improvements.

Eventually the simplest solution was to start fresh with the latest Sitecore example repository and carefully apply our customizations on top of it.
 

Conclusion

The key lesson is straightforward. If you are building on top of Sitecore’s example repositories and want to maintain them over time, treat the original files as foundational. Avoid modifying them directly wherever possible and extend functionality through separate layers instead.