You have a problem, and nobody can tell you how bad it is.

The outcome

What changes once it’s dealt with

• You know how bad it is. A written assessment of what is fragile and what failure would look like, which you can take to a board, a client or an auditor.
• Problems are found before your customers find them. Failures become visible and recoverable instead of being reported to you.
• The workaround stops being load-bearing. The check someone does every morning is automated, with a trail you can trust.
• Change becomes something you plan, not something you avoid.
• The knowledge stops living in one person’s head, which is usually the real risk.

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 → · What people say about working with me →

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.

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.

Fixed-price review

Start with a fixed-price review

If you want that assessment before you commit to anything else, it comes as a fixed-scope review, quoted as a fixed price agreed in writing after a free 20-minute call. Pick the one that matches what you are worried about:

• Legacy Health Check: what is fragile in an ageing system you depend on.
• Integration Review: how your systems and third-party integrations fit together, and what breaks first.
• Backend API Audit: an API layer you are relying on, before you build further on top of it.

Not sure which one fits? Say so when you get in touch and describe the system.

Ask about a fixed-price review Compare the three reviews

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 pipeline that collects and checks email-security reports, and raises an alert when something looks wrong. It ran on a server that was paid for around the clock, although the reports only arrive in bursts, so most of the bill was for a server waiting. Moving it to hosting that is paid only while it is working took the running cost from £26.83 in its last full month on the old host to £2.21 in its first full month on the new one (September 2026), doing the same work.

The part worth noticing is not the saving. Before moving it, I made sure it could never process the same report twice, even if a run was interrupted halfway, because cheaper pay-per-use hosting and automatic retries together will happily do the same work twice if you let them. The cost reduction was the last step, not the first.

Commercially

What this is worth commercially

I am cautious about benefit claims, because most of them are unfalsifiable. What I can say concretely is set out under what changes once it’s dealt with.

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. What I can show you is the shape of it:

Common questions

What people ask first

The questions that come up on almost every first conversation.

All frequently asked questions →