What I deliver.
I help teams design, build, and ship production AI systems — from LLM proofs-of-concept to scaled, observable deployments.
- LLM & RAG Systems
- AI Agents & Automation
- ML Strategy & Audit
- Full-Stack Engineering
- Mobile Apps (iOS & Android)
Five things I build.
Open any of them for the full picture — what tends to break, what gets built, and how the work runs.
Four rules I don't bend.
Measured, not asserted
Every claim about quality, latency, or cost comes with a number and the eval that produced it. "It feels better" is not a result.
Weekly, not at the end
Something demoable lands every week. You are never more than seven days from knowing whether this is going well.
You own all of it
Code, evals, docs, dashboards, and store accounts stay yours. Nothing is architected so that it only keeps working while I’m around.
The honest no
If the AI part isn't the right answer — or a two-day script beats a two-month build — I'll say so before the budget goes in.
How I work.
Same three beats whichever problem it is — only the length changes.
- 01
Discovery
One week. We agree on the goal, the constraints, and what "working" means in numbers — before anyone writes code.
- 02
Build
Two to six weeks of eval-driven implementation with a demo every week. You see working software, not status reports.
- 03
Ship
Deployment, observability, a runbook, and a handover session — then a retrospective on what we actually learned.
Industries I've already shipped in.
Domain context saves weeks. There's a good chance I've seen your compliance constraint or your integration before.
- AI-Driven Platforms
- SaaS Products
- Sales & CRM Automation
- Real Estate (UK)
- Insurance
- FinTech & Banking
- E-Commerce & On-Demand
- EdTech
- Health & Fitness
- Travel & Tourism
- Hospitality (Hotel Management)
The questions I get asked first.
How do you start on something new?
A conversation about what you're actually trying to build, before any code. If it's a fit I'll write up how I'd approach it; if it isn't, I'll say so and usually point you somewhere better.
Do you work alongside an existing team?
Usually, yes. Most of the work I do is embedded alongside other engineers — in the same repo, the same standups, the same review process — rather than off building something in isolation.
Can you work across timezones?
Yes. I work remotely with teams in other timezones, with a few hours of guaranteed overlap each day and everything important written down, so no decision depends on catching me live.
Who owns what gets built?
You do — the code, the evals, the docs, and the runbook. I don't architect things so that they only keep working while I'm around, and I stay reachable for questions afterwards either way.
What if the AI part isn't the right answer?
Then I'll say so. More than once the most useful thing I've done was talk someone out of a build, or point out that a two-day script beat the two-month version.
Have a use case in mind?
Tell me about it. I'll help you think it through — or tell you honestly if it isn't worth building.