With build-time integration — say a microfrontend is imported as an npm package inside a monorepo — walk through what has to happen for one team's UI change to reach production, and what that implies for release cadence across teams.

## What build-time integration actually does Build-time integration means a microfrontend's source code, or a compiled artifact of it, is pulled into the host application's build pipeline and becomes part of a single deployable bundle. There are two common flavors: - **Publishing the microfrontend as a versioned npm package** that the host lists as a dependency and installs during install. - **Placing the microfrontend's code directly inside a monorepo** that the host imports from via a workspace path. In both cases, the browser never independently fetches the microfrontend's code at runtime — bundlers trace the import graph, tree-shake, and emit one host-controlled bundle at build time. There is no separate file the browser requests on its own; it is already inlined into whatever chunk the host's bundler decided it belongs to. ## What the pattern buys The reason this pattern exists is that it buys back everything runtime integration gives up. Because the microfrontend's code is present at compile time: - the type checker can verify props and shared interfaces across the team boundary; - the bundler can dedupe and tree-shake shared dependencies precisely; - and there is exactly one artifact to test, version, and roll back. Teams choose it when the coupling between microfrontends is tight — shared design-system primitives, a shared state store — or when the org isn't ready to operate the extra infrastructure that independent deployability demands. ## The trade-off: one release train The trade-off is exactly what the question is probing: release cadence stops being per-team and becomes per-host-artifact. To get a one-line CSS fix from a checkout microfrontend into production, the sequence is: 1. The checkout team merges their change. 2. If it's a published package, they bump the semver, publish to the registry, and open a PR against the host to bump the dependency; or in a monorepo the change simply lands in the shared tree. 3. The host's CI pipeline runs its own full build and test suite, which now also exercises checkout's code as part of the host bundle, and its own deploy job. 4. Only after that deploy completes is the fix live. If the host deploys weekly, checkout's fix waits up to a week even though checkout's own code was ready on day one. This is deployment coupling: N teams share one release train, one CI queue, and one rollback unit. ## Failure modes Production failure modes from this coupling are mostly about blast radius and pipeline contention. - **Shared blast radius.** Because everything lands in one artifact, a failing test or a broken build anywhere in the tree blocks every team's release — a bug introduced by an unrelated catalog team can hold checkout's urgent fix hostage in CI. - **Pipeline contention.** Monorepo build times also tend to grow with the number of participating teams unless the org invests in affected-graph build tooling like **Nx**, **Turborepo**, or **Bazel** that only rebuilds and retests what actually changed; without that investment, CI queues get long and teams start batching changes to amortize the pain, which further slows cadence. - **Invisible coupling.** There is also a subtler failure mode: because the coupling is invisible day-to-day, teams underestimate how entangled they've become until a major version bump of a shared dependency forces a coordinated multi-team migration all at once. ## Where it shows up A concrete example: enterprise design-system consumers historically ship shared component libraries as versioned npm packages that product teams import and bundle at build time — this is build-time integration even when the overall system is loosely described as microfrontends. Each consuming team still has to bump the design-system version and redeploy their own app to pick up a fix, which is exactly the deployment-coupling trade-off, just scoped to a library rather than a whole microfrontend. On the other end, teams that outgrow this — **Spotify's** desktop client and **Zalando's** early microfrontend work among them — moved toward runtime-loaded remotes specifically to decouple release trains once the number of independently-owned frontend teams grew large enough that a shared release train became the bottleneck. The lesson: build-time integration isn't wrong, it's a deliberate trade of per-team deploy autonomy for compile-time safety and operational simplicity, and the right call depends on how many teams share the boundary and how often they need to ship independently.