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, a global ideas-and-collaboration platform built on the Twine product, adapted with custom components to Shell's needs - and to Shell's compliance and documentation standards, which is where the real work was. An education in what "enterprise-ready" actually means when a supermajor is the one defining it.

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 engagements are where my defaults were set. Infrastructure as code, so environments can be rebuilt and proven rather than described. Audit trails and access control designed in, not bolted on. Documentation written for the person who has to approve the system, not just the one who has to maintain it. And a habit of asking "who's accountable for this decision?" before asking "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.