Service 03
Where models become products.
Most AI projects work in a demo and fall apart in production. The gap is retrieval quality, cost control, latency, failure handling and evals — the engineering, not the prompt. That gap is the work I do.
Start a project ↗What I build
- RAG pipelines
- Retrieval over your documents, done properly — chunking, embeddings, reranking, and the evals that tell you whether answers are actually grounded.
- Agentic systems
- Multi-step agents that plan, call tools, and recover from failure. LangGraph, tool calling, MCP servers.
- LLM integration
- Adding AI to an existing product — streaming, structured output, fallbacks, and rate-limit handling that degrades gracefully.
- Cost & latency work
- Getting an AI feature that works but costs too much down to something you can afford at scale. Caching, model routing, prompt compression.
- Evals & guardrails
- Test suites for non-deterministic systems, so you can change a prompt without silently breaking everything downstream.
Stack
- Orchestration
- LangChain · LangGraph · MCP · Tool calling
- Models
- Claude · GPT · open-weight models · structured output
- Retrieval
- pgvector · Pinecone · Qdrant · hybrid search · reranking
- Production
- Streaming · evals · tracing · cost monitoring
Whether this is a fit
A good fit if
- You have an AI feature that demos well and breaks under real use
- You need retrieval over your own data and want it actually accurate
- You want someone who will tell you when AI is the wrong solution
Probably not if
- You want a chatbot bolted on because the board asked for AI
- You need model training from scratch — that's a different specialism
- The value depends on data you don't have and can't get
Questions I get asked
Do I need RAG or fine-tuning?
Almost always RAG first. Fine-tuning changes behaviour and format; retrieval changes knowledge. Most people asking for fine-tuning want retrieval. I'll tell you which you actually need before taking the work.
How do you charge?
Three ways, whichever suits the project: an hourly rate, a monthly contract for ongoing work, or milestone-based payments tied to agreed deliverables. We settle which one on the scoping call, before any work starts.
Which model should we use?
Depends on your latency, cost and accuracy constraints — and it should be swappable. I build the integration so switching models is a config change, not a rewrite.
Can you reduce our existing AI costs?
Usually yes, often substantially. Caching, routing cheap queries to smaller models, and cutting context bloat are the common wins.
How do you know it works?
Evals. A test set with expected behaviour, run on every change. Without it you're editing prompts and hoping, which is how AI features quietly regress.
Related writing
- RAG vs Fine-Tuning — When Each Actually WinsA decision procedure for choosing between retrieval and fine-tuning, including what fine-tuning genuinely can't do, what each really costs, and the evaluation work nobody budgets for.
- Building an AI Chatbot with OpenAI — Beyond the 20-Line DemoWhat it actually takes to ship a production AI chatbot on the OpenAI API — streaming, RAG, tool calling, cost control, and the guardrails the tutorials skip.
- Prompt Engineering That Survives ProductionField notes on LLM features breaking in production — silent model upgrades, unparseable output, prompt injection — and the practices that came out of each failure.