The estate is around twenty repositories — apps, satellites, workers, specs — and they share forty-seven packages from a single workspace. Design tokens, the dashboard shell, the module SDK, the AI client, the auth helpers and the receipt emitters are each written once, versioned once, and installed by every surface that needs them.
Two apps is fine. You copy the button, you copy the token file, and you move on. At six apps the copies have drifted, and the drift is invisible until a customer sees two different shades of the same accent colour on two pages that are supposed to be the same product.
Consolidating is the obvious answer and the expensive one, because a shared package is a commitment: every change is now a release, and every release can break something you are not currently looking at.
Releases go through changesets, so a change carries its own version intent and the publish is mechanical rather than remembered. Consumers install from a private registry, which keeps the private packages private without a second distribution mechanism.
A shared package is a commitment: every change is a release, and every release can break something you are not currently looking at.
The part we underestimated is that the coupling needs its own watchers. Peer-dependency ranges drift silently and surface much later as an install failure inside a deploy, not as a test failure, so there is now a weekly check for range violations and a second one for packages falling behind across the estate.
An accent colour, a spacing scale, a paywall check or a receipt emitter is defined in one file. Changing it changes it everywhere, which is the point, and also the reason the checks exist. The alternative — the same decision made independently in twenty places — is not simpler. It is just slower to discover.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog