$ man context-wiki/monorepos

I was planning one website. Then the agent and I scoped the architecture and realized one site could not hold everything. Three audiences, three domains. shawnos.ai for my personal brand. thegtmos.ai for GTM engineers. thecontentos.ai for content creators. But I did not want three separate repos with three sets of dependencies, three deployment pipelines, and three copies of the same design system. So we built a monorepo. One repo that holds all three sites with shared code between them. One push deploys all three. One design system. One source of truth.

PATTERN

Turborepo manages the orchestration. It knows which projects depend on which packages and builds them in the right order. apps/shawnos/ is the shawnos.ai site. apps/gtmos/ is the thegtmos.ai site. apps/contentos/ is the thecontentos.ai site. packages/shared/ holds components, styles, data files, and utilities that all three sites use. When I update a shared component, all three sites get the update. When I add a new data file (like this wiki), I put it in packages/shared/data/ and any site can import it. The shared package is the bridge. Sites import from it. They never duplicate code.

PRO TIP

One commit can update all three sites. If I fix a bug in the shared navigation component, all three sites get the fix in one push. No syncing across repos. Shared types and data. The wiki data files, the RPG progression system, the voice components. All live in packages/shared/. Write once, use everywhere. Consistent dependencies. All three sites use the same version of Next.js, React, and every other package. No drift between repos. One deployment pipeline. Push to main, Vercel builds all three, all three go live. The /deploy skill handles one repo, not three.

ANTI-PATTERN

Monorepos are not free. Build times are longer because Turborepo builds multiple projects. The initial setup is more complex than a single-site repo. Package imports need to be configured correctly (exports in package.json, TypeScript path resolution). And if you break the shared package, you break all three sites at once. The tradeoff is worth it if you have shared code between projects. If your projects are truly independent with no shared components or data, separate repos are simpler. My three sites share a design system, data files, components, and utilities. The monorepo saves me hours every week. If they shared nothing, I would use three repos.