We build each organisation its own system, and every one of those systems uses one shared foundation. This changes more than the software of one organisation. It changes the market itself. It changes who builds a system, who owns it, and who competes for the work. It also changes what happens to a price each year. This article explains how that market works. It shows why a system of your own now costs less than the rent. It shows why the price falls as more organisations join. It shows why the benefit belongs to the members, and not to a supplier. It also compares this way of working with four approaches that already exist.
Connect with us about your sector · · Replies within 24 hours
It is a market where two organisations share a record without an integration project. Their systems already agree about a person, a case and a payment.
The opposite requirement applies today. Each supplier holds its own definitions. Each pair of systems therefore needs a mapping rule, and a developer writes that rule.
The number of rules increases with the square of the number of systems. Ten systems need as many as 45 rules.
Interoperability is therefore not a function that a supplier adds. It is a property of the design of the market.
The Government Digital Service published a common architectural model for local government on 14 April 2026. The publication makes three findings.
Councils "buy from the same limited market of technology suppliers and implement similar capabilities independently." The results are "duplicated effort, fragmented assurance, and avoidable risk."
The publication does not make the model necessary. It offers "a shared way of describing technology that still allows for local choice."
That decision is correct. One common vocabulary applies, and each organisation still chooses its own system.
The business reasons stop the correction.
The Local Government Association reports that a few suppliers hold each software market. Buying power is therefore not equal. Suppliers set the terms, because councils have few alternatives. Low competition also decreases the pressure to release security patches, and this increases the cyber risk.
A supplier gets no advantage when your data moves easily to a competitor. Lock-in is the business model, and it is not a defect.
Three costs are the result. Each organisation in the sector pays all three costs.
They do not include enforcement, and they do not include capacity. Both requirements are practical.
A published architecture describes the correct approach of the systems. It is a separate document. A system can become different from that document, and no failure happens at that moment. The reports continue, and the document slowly becomes incorrect.
The second requirement is more important. A common model needs an organisation to apply it. Most sectors have no technical staff for that work.
One sector has a measurement. The 2025 Adult Social Care Provider Technology Survey found that 27% of CQC-registered providers use no technology for care. Providers that support 200 or more people reach 89% use. Providers that support 10 or fewer people reach 40% with no use.
It needs three requirements. One organisation cannot meet the second requirement or the third requirement alone.
Requirement three separates this approach from a shared service. A shared service holds your systems. This approach holds the definitions, and you hold your system.
We explain the technical requirements in bespoke software for a whole sector. We explain the costs in the cost to own and run your own systems.
A bespoke build is too expensive for most organisations today. The build must include identity, access control, encryption, retention rules and an audit record. Each organisation pays for those parts again. A product from a supplier is therefore the cheaper choice, and that supplier then holds the meaning of your data.
A shared foundation already contains those parts. The remaining work is only the part that is specific to your organisation. A bespoke build therefore becomes small, and its cost falls below a subscription.
This is the practical change. Ownership stops being the expensive option.
Four requirements of the market then change direction.
| Requirement | The market today | The market with a shared foundation |
|---|---|---|
| The price each year | A subscription increases. | The fee decreases as the membership increases. |
| The cost to leave | It increases with each year of use. | It stays low, because you own the system. |
| The benefit of more users | The supplier gets the benefit. | The members get the benefit. |
| The competition | Buyers choose between a few products. | Buyers choose between suppliers of build work and support. |
The last row is the largest change. Today you choose a product, and that product then holds your data. With a shared foundation you own the system, and you choose the organisation that builds and supports it. That choice stays open each year.
The benefit also increases with each new member. Two members that use one dictionary share data with no integration work. Ten members share data the same way. This benefit belongs to the members, and it does not belong to a supplier.
We build each organisation its own system on one shared foundation. All of these systems run together from the first day.
For each sector we then create a sector technology hub with the first organisations of that sector.
We are developing the first hub for the care home sector.
| Approach | What the members share | What you own |
|---|---|---|
| A shared service | One system for all members. | No asset. You use a service. |
| A buying group | Buying power against one supplier. | A licence, at a lower price. |
| A published standard | A document. Each supplier writes its own rules to match it. | The product that your supplier sells you. |
| An innovation network | Research, training and practice. | No asset. The network builds no systems. |
| A sector technology hub | The dictionary, the specifications and the build capacity. | Your own system, and your data. |
The last row shows the difference. Your system stays yours, and the members share the meaning.
A county council runs housing, revenues, social care and waste as separate systems. Each system holds a person, and each system uses a different definition. The council keeps a mapping rule for each pair. With one dictionary the four services use one definition of a person, and no mapping rule exists.
A care group with three homes runs a records system, a rota tool and a family portal. Three systems need three mapping rules. The registered manager still cannot get one occupancy figure. The arithmetic is the same as the council arithmetic, and the cost is smaller.
The care home software and school software pages cover the sector in detail. Our guides to the MODS data standard and the four methods to record meaning explain the mechanics.
It is a market where two organisations share a record without an integration project. Their systems already agree about a person, a case and a payment. Today each supplier holds its own definitions. Each pair of systems therefore needs a mapping rule. The number of rules increases with the square of the number of systems.
GDS published a common architectural model for local government on 14 April 2026. It states that councils buy from the same limited market of suppliers, and that they implement similar capabilities independently. The results are duplicated effort, fragmented assurance and avoidable risk. It also states that there is no common model or shared language.
A supplier gets no advantage when your data moves easily to a competitor. Lock-in is the business model, and it is not a defect. The Local Government Association reports that a few suppliers hold each market. Buying power is not equal, because councils have few alternatives.
A bespoke build is too expensive today. Each organisation pays again for identity, access control, encryption, retention and audit. A shared foundation already contains those parts. The remaining build is small, and its cost falls below a subscription. Four requirements then change direction. The yearly price decreases. The cost to leave stays low. The members get the benefit of more users. Buyers also choose between suppliers of build work, and not between products.
It is a shared organisation that builds and supports the system of each member. It follows the regulation of the sector. It writes one specification for each change. It then applies that change to each member system. A board from the sector charter agrees the priorities, the standards and the fee. The hub runs at cost, so each new member decreases the fee for all members.
A shared service runs one system for all members, and you own no asset. A sector technology hub shares the dictionary, the specifications and the build capacity. You own your system, your data and your instance, and that ownership continues after you leave.
We build each organisation its own system on one shared foundation. All of these systems run together from the first day. We then create a sector technology hub with the first organisations of that sector. We are developing the first hub for the care home sector.
Connect with us about your sector · · Replies within 24 hours