Digital delivery hub
The shared kit we build from.
This is the capability half of the solution foundry: what an initiative inherits on the day it starts, so it begins mostly built. The numbers here are current status rather than a plan, and anything that is a target or a working hypothesis says so where it appears.
The mental model
How it fits together.
Everything sits on one ladder, from the smallest building block up to the whole service experience. The lower rungs follow Atomic Design, the upper rungs follow service design. Components are one rung, capabilities sit higher up, and product features are assembled from both.
The two highlighted rungs, capabilities and components, are what the hub catalogues. Product features sit one rung up and are built by each initiative from these shared capabilities.
Worked example
One product, assembled from the kit.
Cyril, the MedIQ medication companion, built from shared capabilities and components rather than from nothing. Illustrative.
Segment and job to be done
- Segment
- Vital statistics and everyday regimen
- Trigger
- Three medication points a day, plus running low
- Motivation
- Record and be reminded of doses, reorder in time
- Outcome
- A reliable log, timely reminders, easy repeat prescription
Inherited from the hub, unchanged
Shared, configured for this surface
Built fresh for Cyril
One flow, decomposed: log a dose
Six inherited, five configured, three built fresh. That is a count of the features worth naming, not a measure of effort. Most of what Cyril actually runs on, identity, storage, hosting, the design system, is not in that list because nobody would think to name it, and that unnamed majority is the part that gets inherited.
The architecture
Nine-box technology grid.
The central technology architecture, framed as a service blueprint. Three layers (Act, Think, Sense, evolved from Data, Interface and Context) across three lanes (frontstage, backstage, support), with the customer journey as the context that sets it all off. Components live in Act, frontstage. Capabilities map across the whole grid.
A grid of nine cells. The three rows are Act, where people do things, Think, where the platform works things out, and Sense, where it takes in what is happening. The three columns are frontstage, what the user touches, backstage, what happens out of sight, and support, the shared foundations everything runs on. Each cell is described below in that order, row by row. The two buttons that follow switch every cell between an experience description and the technologies behind it.
An evolution, not a rewrite
From the Digital Delivery Hub to here.
The Digital Delivery Hub set out the idea: a shared platform where capability, community and commercial scale work as one, turning innovation into repeatable delivery. The original mapped nine foundational capabilities into three tiers. We have kept the tiers and given them a second dimension.
Data to intelligence → Think
Collect, correct, curate, compute, communicate, now split across the grid: collect and curate in support, compute in backstage, communicate frontstage.
Interface innovation → Act
Optimising interfaces and systems automation, now UX at the frontstage, automation and AI agents backstage.
Context enablers → Sense
The how, where and what specific to industry, location and limitations, now the sensing layer: surfaces, connectivity and infrastructure.
The nine original tiles did not disappear, they redistributed into the grid, and AI moved from a single tile to a layer running across all nine. This page is the capability pillar of the hub. Community and commercial scale are its other two.
The catalogue
What is in the inventory.
The full registries run to several hundred rows and live in the working spreadsheets rather than on this page. The shape of them is the useful part.
123 components, by category
Standardised from a 220-entry survey across six MIT-licensed libraries. For build we adopt two, one per platform: shadcn/ui on web and React Native Reusables on mobile. The other four stay as a reference catalogue, because running six design systems is more than anyone can maintain.
158 capabilities, by surface
Two tiers: a universal core of 73 that every surface shares, plus 85 that belong to a specific surface. Product features are assembled from these. The heaviest concentration sits in Act, frontstage and Act, support, which is where most of what a user touches actually lives.
Why it is fast
Build less, integrate more.
The kit exists so we assemble products from proven parts and build only what differentiates. Roughly:
This split is a working hypothesis to test against the first builds, not a measured average. The same caveat applies everywhere it appears on this page.
What we integrate rather than build
Industrialised individualisation
Build once, reuse across every initiative.
The kit is not built per product. It is the shared core of the hub, built once and inherited by every initiative: the efficiency of a standard platform with the fit of a bespoke build. Each new initiative starts mostly built, and only the differentiating slice is its own.
What any initiative is made of
The first two bands, roughly 90%, come from a mature hub. Only the last is built fresh. That 90% is the target we are building towards rather than an average we have hit, and the initiative names above are illustrative.
Configured, or regenerated?
There is a version of this that ages badly. Build one system, make it configurable, then add a switch every time an initiative needs something different. The shared core thickens, nobody dares touch it, and eventually forking costs less than configuring. That is the ordinary fate of a platform, and we are not aiming at it.
Configuration was always the price of regeneration being expensive, and it is not expensive any more. So what is worth holding is not the code. It is the specification and the evidence: what this initiative needs, what has already been proven, what it inherits. From those, a variant can be regenerated rather than configured, which is the same reason a component in the registry is a unit of proof rather than a unit of code.
This is an ambition, not a description of today. What exists now is a componentised kit and a registry. The bet is that as generation keeps getting cheaper, the configurable seventy per cent stops being a set of switches and becomes a set of specifications, and the hub's value moves further from the code and further towards the proof. It is the direction the wider field is moving in too, and it is the one we are building for.
How reuse actually works
Three kinds of reuse, not one.
Reuse is not a single thing, and pretending it is would be naive. The hub works at three levels, each with a different mechanism, coupling and owner.
Shared services
Run once, consumed by all: identity, payments, the data platform, the AI gateway, comms. One managed, multi-tenant instance, versioned with backward compatibility. This is the actual platform, and where most central engineering goes.
Shared components and capabilities
The UI kit and capability templates. Initiatives copy them in and adapt. Low coupling, the initiative owns its copy. Reuse here is by adoption, not dependency, so no initiative is blocked by a central release.
Initiative-specific
The differentiating slice. Built fresh, owned entirely by the initiative, never forced into the shared core.
Governance: a capability earns its place in the shared core once it is proven across two or more initiatives. It graduates upward, it is not mandated downward. Tenancy: data is isolated per initiative and per vertical, so a regulated initiative and an unregulated one never share a tenant, and compliance posture is set per tenant rather than assumed across the hub.
Where the advantage compounds
The moat is not the components.
We are honest about this. The components are open source and the foundations, identity, payments, cloud, are bought. Anyone can assemble those. The advantage compounds in three places a competitor cannot simply copy.
The inventory, and the speed it buys
Every initiative adds to the shared inventory, so the cost and time of the next one keep falling. The moat is the accumulated, integrated, proven kit and the velocity it confers. A flywheel, not a single asset.
Cross-initiative data and intelligence
The Think layer is where value compounds: governed, reusable data and models that improve as more initiatives contribute, within strict isolation. This is the defensible core, and why the hub is worth funding in its own right.
The co-operative model
A collaborative ecosystem, co-operative capital and market partnerships, shared purchasing power and collective scale. An organisational advantage a lone product company cannot replicate.
Honest caveat: cross-initiative data effects only work inside careful compliance boundaries. We treat that as a hard constraint, not a free network effect.
Where we are today
A staged build, honestly framed.
This is a deliberate, staged build rather than a finished platform, and being straight about that is the point.
The portfolio
Sixteen initiatives at very different stages: some ideas on paper, some in active fundraising, a few with demonstrators. The hub is being built alongside them, not ahead of them.
The raise
We are raising for both the central hub and individual initiatives. The hub's case is the leverage it gives every initiative; each initiative's case is its own market.
What is real and what is catalogued
The 123 components and 158 capabilities here are the map of what a mature hub provides, not a shipped inventory. Build readiness is tracked in the registry and most of it is still to come. We would rather show the plan than overclaim a platform.
The bet
Componentise the experience layer, centralise the intelligence layer, and a small team can launch many initiatives far faster than building each from scratch. We are proving that deliberately, one demonstrator at a time.
People are our business. Collaboration is our culture.
This page is the capability argument. If it holds up, the rest of the case is on the Solution Foundry page, and there is a way in from there.