Mission-critical platforms
Five engagements for the NHS, government and energy, where the work was hosting, assurance and sign-off rather than the code.

01The brief
There’s a category of client where the usual rules of web development don’t apply. A government department that can’t discuss where its website is hosted. A health service where downtime has a human cost. A supermajor whose compliance requirements arrive before the brief does. A race venue with one weekend a year that actually matters.
No single brief covers them, but between 2013 and 2018 I kept ending up in these rooms, and the engagements taught the same lesson from five different angles. When failure isn’t an option, the engineering is the easy part. What these clients are really buying is assurance: evidence, process, and someone willing to be accountable for the answer.
What the work involved
A sensitive government department. On paper, the FCO Services website (now FCDO Services) was a simple WordPress build. In practice, the CMS was the least important part. The engagement lived in the hosting, the security posture, and the assurance work a sensitive department requires before anything goes live. My first lesson in the gap between “it works” and “it’s approved to work”.
The NHS. Geni, the platform behind the NHS graduate management training scheme. Not glamorous, and that’s the point: infrastructure for an organisation where “it broke” is never an acceptable answer, built to be dependable rather than impressive.
A government department, no code at all. UK Trade & Investment brought me in to advise on whether to renew the technology partner behind a core system or select a new one. An independent review of the options, costs and risks, delivered so the department could make the call with confidence. Sometimes the most valuable engineering output is a well-argued document.
Shell. Ideas 360 is a global platform for ideas and collaboration, built on the Twine product with custom components designed for Shell. Fitting it to Shell’s compliance and documentation standards was most of the work, and it set the bar I now hold other products to before I’d call them enterprise-ready.
A world-famous motorsport venue. A multi-lingual events website with ticket sales, and live text and voice chat wired into an on-premise Avaya phone system over AWS PrivateLink, with AudienceView handling ticketing. Web infrastructure and enterprise telephony behaving as one system, for an audience arriving from all over the world on a handful of days when nothing is allowed to fail.
The common thread wasn’t a technology. It was that nobody in the room could afford a second attempt.
Where it stands
These five engagements are where my working habits come from. Infrastructure as code, so environments can be rebuilt and verified rather than described. Audit trails and access controls designed in as features rather than bolted on later. Documentation written for the officials who approve the system as well as the staff who maintain it. And the question I ask before “how do we build it?”, which is “who’s accountable for this decision?”
That is the posture I bring to regulated FinTech, risk intelligence and every fractional CTO engagement: the standards of clients who couldn’t afford mistakes, applied by default, including where they aren’t strictly required.
Wrestling with something similar?
A short email is plenty. Tell me where you are and what you're wrestling with.