An abstraction with one consumer is a guess

The month after the shared core existed was spent restructuring it, which is the usual sequence and not a pleasant one. Modular architecture, a migration guide for the consumers of the previous shape, documentation of how the bundle actually fits together.

The restructure was necessary because the first design had exactly one consumer and had therefore been validated against nothing. It worked. Working was not evidence that the boundaries were in the right place, and the second consumer found three that were not.

Write the interface before the implementation

The cheapest experiment available on a design question is to write down what the thing will look like to whoever calls it, before any of it is built. A short document: what problem this solves, what the surface is, what it explicitly does not do, what gets given up by choosing it.

That document costs an hour and routinely kills a week of work, because a surface that is embarrassing to describe is usually embarrassing to use. The failure mode it catches is the design that is coherent from inside the implementation and incoherent from outside it, which is the most common way an abstraction goes wrong and the hardest to notice while you are building it.

It also produces a record of why the boundary is where it is. Six months later that record is the difference between a considered constraint and an arbitrary one nobody dares touch.

The migration guide is the real test

A better test than any document: try writing the guide that moves an existing consumer from the old shape to the new one. If that guide is short, the boundary was real and the change was contained. If it sprawls — touch this, then that, then update these four call sites and this configuration — the boundary was decorative and the coupling was always there.

This is uncomfortable in the productive way, because it is the one artifact that cannot be argued with. You either can describe the change in a few steps or you cannot.

It follows that a shared core should be judged on the cost of changing it rather than the elegance of its current state. A beautiful architecture that cannot be modified without a coordinated migration across every consumer is a monolith with extra packaging.

What the core is allowed to own

The rule that settled it: the core owns concerns that are identical everywhere, and nothing a venture might reasonably want to differ on. Identity, billing, data access, deployment, evidence capture. Not workflow. Not domain modelling. Not anything shaped by the specific market a venture is in.

That line is drawn conservatively on purpose. A core that owns too little costs a venture some duplicated work, which is annoying and bounded. A core that owns too much means a change one venture needs is a change every venture inherits, and the shared layer becomes the thing everybody is waiting on. The second failure is much harder to reverse than the first.