Mission-critical platforms

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 - the system managing people through a multi-year programme. 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. Proof that sometimes the most valuable engineering output is a well-argued document.

Shell. Ideas 360 is a global platform for ideas and collaboration. It is built on the Twine product and includes custom components designed for Shell. We adapted the system to meet Shell’s specific compliance and documentation standards. This process required significant effort. The project taught us the requirements for a product to be considered enterprise-ready by a supermajor company.

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

I established my standard practices during these projects. I use infrastructure as code so that we can rebuild and verify environments instead of just describing them. I design audit trails and access controls as core features rather than adding them later. I write documentation for the officials who approve the system as well as the staff who maintain it. I always ask “who’s accountable for this decision?” before I ask “how do we build it?”

That’s the posture I now 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 technically aren’t required.