Build Graph Scoping

A monorepo's advantages — atomic cross-package changes, one dependency version, a single review flow — are real and independent of scale. Its cost grows with scale and is concentrated in one place: if every commit triggers a full build and test of every package, the pipeline becomes the bottleneck and the repository becomes unpleasant to work in.

Scoping fixes this by deriving the dependency graph and building only what changed plus what depends on it. A change to one application's route builds one application; a change to the shared design system builds everything that consumes it, which is correct and is also the signal that the design system is a high-blast- radius dependency deserving careful review.

Two things make it work in practice. Remote caching, so a package unchanged since the last build is restored rather than rebuilt, which is where most of the time saving comes from. And accurate dependency declaration, since an implicit dependency the graph does not know about produces a build that passes and a runtime that breaks.

The failure mode is a graph that has degraded into everything depending on one utility package, at which point every change rebuilds the world and the scoping provides nothing.