AI production reliability
Your AI pilot demos well. I find out why it isn’t ready for production — and what to fix first.
The problem
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.
The engagement
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,500Fixed · quoted upfront
A prioritised findings report — what will fail, how it will fail, and how likely it is
A remediation plan your own engineers can execute, sequenced by risk and effort
Failure-mode analysis covering silent failures, retry and idempotency gaps, data-quality edge cases, and behaviour under concurrency and load
An observability assessment — whether you would actually find out when it breaks
A walkthrough call with your team
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.
Selected work
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.
Background
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.
Get in touch
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.