Architecture
What an Operations Library is for
The architectural reason Cadence, Relay, and Revalidate share a backbone — and what that means for the cost of running them as one product line vs three separate ones.
Most healthcare software accumulates features. The system that was originally a complaint log gets a risk register added to it, then a policy library, then a meeting tool, then an audit module — each addition shaped by what was easiest to build given the last addition, and each adding a bit more design drift, a bit more configuration to maintain, a bit more cognitive load on the person at the desk.
The Operations Library is the architectural decision to do the opposite. The shape of an incident is defined once, in a schema. The shape of a policy is defined once. The shape of a referral is defined once. Apps that need to render any of these read from the schemas. There is one schema for incident; Cadence and any future product that touches incidents both consume it.
What this gives us at a code level
The shared design system is one set of tokens. The shared UI package is one set of components. A “status pill” in Cadence is the same atom as a “status pill” in Relay. A change to the status pill — a contrast adjustment, a radius tweak, an accessibility fix — happens once and is true everywhere. There is no design drift across products because there is no second design system to drift from.
At a content level, the same property holds. The CQC framework domains are mapped once. The GMP 2024 domains are mapped once. When the framework changes — and it does change — the update lands in one schema and propagates.
What this gives us commercially
The cost of running three products on this architecture is not three times the cost of running one. The infrastructure underneath them — the database schemas, the auth model, the deployment pipeline, the design language — is shared. The marginal cost of a fourth product is significantly less than the first.
That has a downstream effect on pricing. A product line built this way can offer pricing that a single-product competitor can’t match, because the per-product overhead is structurally lower. We don’t solve pricing publicly during alpha — that decision is held back until partner conversations validate the thesis — but the architecture decisions made now are what permit whatever pricing eventually lands to be defensible.
What this asks of us
The Operations Library only works if every product is held to the same backbone. The discipline against per-app design languages, per-app schemas, per-app status colours has to be maintained as new products launch. The fastest way to lose the commercial advantage above is to let one product introduce “just this one” exception. So we don’t.