Brittle integrations and legacy systems, made dependable.

At Lloyds Banking Group, I built workforce planning and capacity management tooling used across UK Group Operations — it helped planning decisions get made more consistently, instead of depending on whoever happened to know the spreadsheet.

At Communisis, I worked inside document processing and ingestion environments where reliability was the actual job, not a footnote — finding and fixing the underlying problem instead of patching the same symptom every few weeks.

More recently, I chose to stabilise a live C#/.NET integration rather than rebuild it from scratch, because the business couldn't absorb the downtime a rewrite would have risked — the fix reduced manual effort and cut dependency on a disconnected process, without a single day of disruption to the team relying on it.

Different employers, same pattern: something the business relied on that had become harder to trust than it should have been. I look at the whole problem first, then fix one thing at a time, so we don't break something else.

You work directly with me — one accountable contact from scoping through sign-off, 100% remote, with scope agreed in writing and a 30-day defect warranty included. See the projects this led to →

The situation

Three things usually bring people here

Most of the work I am asked about arrives described as a solution. "We need to rebuild this." "We need to move it to the cloud." "We need to replace the spreadsheet." Sometimes that turns out to be right. Often the real problem is somewhere else, and the proposed fix would have been expensive and would not have helped.

All three are the same underlying situation: something the business relies on has become harder to trust than it should be.

Diagnosis first

What I do first

I look at the whole problem before I change any of it. In practice that means asking why a system exists and who depends on it before asking how to change it, because I started in operations rather than in IT and I have watched a technically correct fix break somebody's morning.

• Reading the code and the data, not just the documentation, because the documentation is often describing the version before last.
• Talking to the people who use the thing daily. They know where it fails. They have usually stopped reporting it.
• Establishing what actually breaks first under change, rather than what feels riskiest.
• Separating the problems that are urgent from the ones that are merely visible.

How that work is actually run, week to week, is set out on how I work.

The deliverable

What a diagnosis produces

A written assessment you can act on without me:

• What is fragile, and what the failure would look like if it happened next week.
• What is costing you effort now, with the effort described in terms you can check.
• The order I would deal with things in, and why that order and not another.
• What I would leave alone, which is usually the most useful section.
• An estimate for anything worth doing, against a scope written down before work starts.

If the answer is "this is fine, stop worrying about it", you get that in writing too. It has happened.

Judgement

Where the judgement goes

Architecture decisions are mostly trade-offs made under someone else's constraints, and the constraint is rarely technical.

A recent example from my own systems: a compliance pipeline collects DMARC and TLS-RPT reports, archives them, analyses them and raises alerts. It was running on an always-on container host. The work is bursty, so most of what was being paid for was the host being awake between runs. Moving it to consumption compute with no always-ready instances took the running cost from £26.83 in its last full month on the old host to a rate under £3 a month on the new one, doing the same work.

The part worth noticing is not the saving. It is that the processing had to become genuinely idempotent first, with each message claimed atomically and any interrupted run recovered before new work starts, because "scale to zero" and "at least once delivery" together will happily process the same report twice if you let them. The cost reduction was the last step, not the first.

Figures are Azure Cost Management actuals for a dedicated resource group. The post-migration rate covers nine days rather than a settled month, and I would rather say that than round it into something tidier.

Commercially

What this is worth commercially

I am cautious about benefit claims, because most of them are unfalsifiable. What I can say concretely:

• You get a written picture of operational risk that you can take to a board, a client or an auditor.
• You stop paying for effort that exists only because something is unreliable.
• The knowledge stops living in one person's head, which is usually the actual risk rather than the technology.
• Change becomes something you plan rather than something you avoid.

What I will not tell you is a percentage. I do not know your baseline, and neither does anyone who quotes you one before looking.

Evidence

Three pieces of work, written up in full

Each one records what was actually wrong, what was tried, and what it cost, including the parts that were awkward.

See the full set of write-ups.

Honestly

When I am not the right answer

• You want a delivery team. There is one of me, and I would rather say so now.
• You want the work done on site. I work fully remotely, all of the time.
• You already know exactly what you want built and want it built to specification with no questions. That is a real and reasonable requirement, and the Freelance route fits it better.
• The problem is genuinely a people or process problem with a technology-shaped label on it. I will tell you that, but I am not the person to fix it.

Two areas people often ask about specifically: business process outsourcing environments and operational systems.

Common questions

What people ask first

The questions that come up on almost every first conversation.

All frequently asked questions →