AI production reliability
PhD, Computer Science · 15+ years consulting · Gold Coast, Australia — working with UK, European and NZ teams
RAND analysed more than 2,400 enterprise AI initiatives and found 80.3% fail to deliver their intended business value. MIT’s Project NANDA found roughly 95% of generative-AI pilots return nothing measurable on the P&L. More than half are abandoned after proof-of-concept.
The cause named again and again is not model quality or prompt design. It is the gap between a demo that works and a system you can trust on a Tuesday morning when nobody is watching it. Retries that silently don’t fire. Extraction that drops records without raising an error. An entry point with no alarm on it. Concurrency limits that reject a job and corrupt a week of data.
That gap is what I work on, and it is engineering discipline rather than AI expertise. Most teams don’t need a better model. They need someone to tell them precisely why the thing they built cannot be relied on yet, and what to fix first.
Five working days. Fixed fee. An independent review of an AI system that isn’t production-ready, and a plan for making it so.
From USD 3,500 — fixed, quoted upfront
You receive:
No tooling to buy, no platform to adopt, no retainer to sign. If you want help implementing the plan afterwards, that’s a separate conversation and an optional one.
Anonymised. Details of clients and systems are never disclosed.
A weekly knowledge-base sync fell a full week behind without alerting anyone. A cloud provider’s per-account concurrency cap was rejecting one of two ingestion jobs; the rejection wasn’t retried, the transform failed, and the checkpoint never advanced. Diagnosed the race, added a bounded idempotent retry that waits for capacity, and covered it with tests for the timeout path as well as the happy path.
A production AI service had error alarms on a legacy path but none on the API that actually served live traffic — so an entire class of failure was invisible. Added alarms at both the resolver and API layers, routed to the team’s existing channels, and replaced a fourteen-widget dashboard nobody read with a single at-a-glance health view.
A document pipeline was quietly dropping line items whenever source text didn’t match expected reference values, producing outputs that looked complete but weren’t. Introduced normalisation for messy real-world wording and a fallback that surfaces incomplete records for human review instead of discarding them — turning invisible data loss into a visible, reviewable queue.
PhD in Computer Science. Fifteen-plus years in consulting, most of it explaining technical systems to people who have to fund them. Currently building and operating production agentic-AI systems — retrieval pipelines, document extraction at scale, and the infrastructure and monitoring underneath them — on AWS, with Bedrock, CDK, Lambda and Fargate, in Python and TypeScript.
I still do this work daily, which is the point. This isn’t advisory from someone who stopped shipping.
I’m on Australian Eastern time, which lines up better than you’d expect: a UK or European working morning is my evening, and New Zealand is two hours ahead of me. Calls during your business hours are straightforward.
Tell me what your system does, what breaks, and what happens when it breaks. If a review isn’t the right thing, I’ll say so.
Based on the Gold Coast, Australia. Engagements are remote.