A regulated product that was not going to ship, shipped.

Where it was

The company had built part of a product and could not get it out. The platform existed in pieces, there was no engineering environment that could carry a change from somebody's branch to a release anyone would trust, and on the path it was on it was not going to launch.

That is a common shape and it is rarely a shortage of code. What is missing is the ordinary machinery a regulated product needs before a release can be a routine event: somewhere for the work to live, environments to run it in, checks that run on every change, and a repeatable way to put a version in front of users. Without it, every release is an act of nerve, and a team that is nervous about releasing stops releasing.

What we put in place

In this order, because none of the later pieces is safe without the first one.

A development environment

Repositories, environments, continuous integration and review gates, so a change is written, reviewed, tested and promoted the same way every time. Built for the founders' own team to work in rather than for us to operate on their behalf.

Release discipline

How a version is cut, what has to pass before it moves, and what happens when something fails: defined, and in use. Discipline that holds only while the supplier is in the building is not discipline.

Completion of the platform

With a path to release in place, the remaining modules were built out and taken to a state that could ship rather than to a state that could be demonstrated.

Delivery to launch

We took the platform to launch with the founders rather than handing over a repository and a document. A first release is where everything the process missed turns up, so it is the release worth being in the room for.

Why it matters in regulated research

Clinical research software is not judged only on whether it works. It is judged on the record it leaves behind: who did what, under whose delegated authority, against which version of which document, and whether all of that can be produced on request.

The platform holds those systems on one inspection-ready record rather than in separate products that have to be reconciled afterwards. Those systems are trial management (CTMS), the electronic trial master file (eTMF), the investigator site file and the pharmacy site file (eISF and ePSF), quality management (eQMS), corrective and preventive actions (CAPA), and digital delegation of authority.

It is built for NHS and hospital R&D, academic research, contract research organisations and mid-market sponsors, and its documentation is aligned to MHRA, FDA and EU Annex 11 expectations.

That is the product's own public description of what it is for, and this page repeats it at that level.

The same test of the record is reaching AI in regulated finance. DIFC Regulation 10 asks a firm in Dubai's financial centre that uses AI on personal data to produce, on request, a register of the system's uses and evidence of when it hands a decision to a person. Our guide to the UAE central bank's AI guidance note shows how its expectations, from testing a vendor's model updates before they go live to keeping a person able to stop any system, become records a supervisor can ask to see. Like a trial record, both have to be designed in rather than reconstructed.

The record reaches the contracts behind a system as well. A UAE bank that buys an AI service has to be able to show that the vendor, and any model provider behind it, leaves the bank owning its data, can be inspected by the central bank and keeps customer data in the country, and the guide to CBUAE outsourcing rules for AI vendor contracts sets out the clauses that make those things true.

The record also has to show who could overrule the system. Qatar's central bank requires a firm it regulates to give every AI system a human oversight protocol, recorded in the register the firm sends it each year, and our guide to human oversight of AI in Gulf banks sets that beside the UAE's three oversight models.

What the founders are left with

The product is live and in market. A launch that was not going to happen on the previous path happened on this one, and it happened in a way the company can repeat.

What stays behind counts as much as what shipped. The development environment is theirs and their own team runs it, the release discipline is theirs and in use, and the next release goes out through the same path that shipped this one. That is the measure we apply to every engagement on these pages: not what runs while we are there, but what the client can maintain, change and build on once we have gone.