We build each organisation its own system on one shared foundation. A reader with experience asks one question first. Bespoke software has never worked for a whole sector, so why does it work now? Aidan Dunphy is Chief Product Officer at Esuasive. He made the objection in Housing Technology in May 2024. In his words, "it just doesn't make sense to take on the cost and risk of developing and supporting processes that are the same across the sector." He is correct about bespoke software as the industry has built it until now. This article explains the five requirements that change the result. It also explains the method that applies one piece of work to many different systems. That method is the part that has not existed before.
Connect with us about your sector · · Replies within 24 hours
The sector does the same work many times, and no organisation carries the shared cost.
Forty organisations each need the same regulatory report. Each organisation orders the report separately. Each organisation pays for the build, the tests and the maintenance. No organisation gets an advantage, because the report is a legal duty.
The objection is therefore correct. A sector that builds forty versions of one report wastes thirty-nine of them.
Two methods change this arithmetic. The rest of this article explains the requirements that these two methods need.
Each system is different, and each system must still agree about the meaning of a record.
A published standard cannot do this alone. A standard describes the data in a separate document. A system can become different from that document, and no failure happens at that moment.
Enforcement is the missing property. The definitions must be a requirement of storage, and not a description of it.
We compare the four methods to record meaning in semantic layer, ontology or knowledge graph.
Usual bespoke software collects migration debt. A new requirement adds a table. That table then needs a migration, a test cycle and a release.
This debt makes a bespoke system expensive in year four. It also stops one piece of work from fitting several different systems.
The database shape must therefore stay constant while the vocabulary increases. A new record type becomes a dictionary entry, and not a table.
This method answers the objection, and most buyers have not seen it before.
A shared add-on module cannot work here. Each member system is different, so one module fits only one of them.
A specification does work. One member orders a new function. The hub then records two items. The first item is the functions that the function needs. The second item is the method to fit it to each different build.
Each other member then adds that function to its own system. The hub does the work one time. The result reaches forty different systems.
The same method carries regulation. The hub follows the rules of the sector. It records one specification for each change, and applies it to each member system.
A specification needs an author, and it needs an engineer to apply it.
Most sectors have no technical staff for this work. The 2025 Adult Social Care Provider Technology Survey found that 27% of CQC-registered providers use no technology for care. Providers that support 10 or fewer people reach 40% with no use.
The capacity therefore cannot stay inside each organisation. It must serve the sector, and it must continue when a member of staff leaves.
The Government Digital Service reached the same conclusion for councils. Its common architectural model reports that council digital teams are small. It also reports that many teams use documents that are difficult to keep correct.
Shared approaches fail when the shared organisation holds the systems. The members then have a new lock-in with a longer notice period.
Three properties stop this result.
We explain the five forms of lock-in in vendor lock-in, what can you prove. That article also lists seven tests to apply before signature.
We build your system on engage.re. The platform already meets the first two requirements.
Requirements three and four are the hub. We create a sector technology hub with the first organisations of each sector. The hub does the builds, records the specifications, follows the regulation, and applies each change to every member system.
Members run at one of two levels. Both levels use the same specifications.
| Level | Method to make a change | What the member pays |
|---|---|---|
| Hub delivery | The hub does the full task: the specification, the build, the verification and the installation. | A flat fee, and an engagement fee |
| Own delivery | The team of the member builds the change, with AI tools if they prefer. They use the specifications and the fail-safe frameworks. The hub examines each change before installation. | A flat fee, and a small examination fee |
The second level becomes more important each year. An organisation with one competent engineer can now make real changes. The specification states the necessary functions, and the framework makes the change safe.
The examination before installation is the requirement that keeps this safe. We explain why verification controls software risk in AI writes code fast.
A county council needs a new statutory return. Today it orders that work, and each adjacent authority orders the same work. With a hub, one authority orders it. The hub then records the specification, and each member applies it to its own system.
A care group with three homes needs the same MODS data fields as each other provider. The fields are a legal duty, and no group competes on them. One specification reaches each member, and each group keeps its current system.
The care home software and school software pages cover the sector in detail. Our guide to the MODS data standard shows a sector-wide requirement in practice.
The sector does the same work many times, and no organisation carries the shared cost. Forty organisations each need the same regulatory report. Each organisation pays for its own build, tests and maintenance. No organisation gets an advantage, because the report is a legal duty.
A specification, and not a module. A shared add-on module cannot fit forty different systems. A specification records the functions that a function needs, and the method to fit it to each different build. One member orders the function, and each other member then adds it to its own system.
A standard describes the data in a separate document. A system can become different from that document, and no failure happens at that moment. The reports continue while the document becomes incorrect. Enforcement is the missing property, so the definitions must be a requirement of storage.
A foundation that stays common, with one enforced dictionary. A database shape that does not change, so a new record type needs no migration. Specifications in place of modules. Permanent technical capacity for the sector. Ownership that continues after exit, for the code, the data and the instance.
Yes, at the own-delivery level. Your team builds the change, with AI tools if they prefer, and they use the specifications and the fail-safe frameworks. The hub examines each change before installation. You pay a flat fee and a small examination fee.
We build your system on engage.re, and the platform already meets the first two requirements. Your vocabulary is declared and enforced. Five constant tables remove the migrations. You own the code, the data and the instance. We then create a sector technology hub that records the specifications and applies each change to every member system.
Connect with us about your sector · · Replies within 24 hours