A monorepo pays off at the second project
Technology
Monorepos get sold on build speed. The reason we run one is that a component, a config, or an icon set exists in exactly one place, and a change to it lands everywhere at once.
We run monogram.io as a Turborepo monorepo, and we have converted a client site into one when a second app had to share its setup. Both times the trigger was the same: a second thing appeared that needed the first thing's foundation.
How
How we actually use Turborepo
- The shared package is the whole point
On M8, our own site, the monorepo holds the styling, components, icons, and Tailwind configuration used across every project in the repository. A new project starts from the existing component library and build setup instead of copying a config directory and letting it drift.
- Two apps, one seam the user never sees
GoHealth had a marketing site and a patient portal that people had to move between without noticing a boundary. We converted the site into a Turborepo monorepo so configuration and components were shared rather than duplicated, then shared authentication across both with NextAuth.
- Caching is why CI stays fast
Turborepo hashes task inputs and replays outputs it has already produced. On a repository with several apps, that turns most pull request builds into a cache hit on everything the change did not touch. The saving grows with the number of packages.
- The task graph has to be honest
Caching only helps if inputs are declared correctly. An undeclared environment variable or a stray file read produces a stale cache hit, which is a worse failure than a slow build because it looks exactly like success. We treat pipeline config as production code.
- Package boundaries are a design decision
Sharing a component library across apps means one team's refactor is another team's breaking change. Boundaries need owners and a versioning story even inside one repository. The monorepo removes the publish step and the version bump, not the coordination that made them necessary.
- When a monorepo is just overhead
One app, one deployable, one team: skip it. You take on tooling, a task graph, and package boundaries, and get back sharing you have nothing to share with. Adopt it when a second app appears, or when a config file already lives in two places.
