Home/What I do
What I do
Four pieces of work covering the whole distance from "we think AI could help here" to something running quietly in the background that your team trusts. Take one, or take them in order.
01
Find the process that's actually worth it
Before anything gets built, you need to know which problem is worth solving — and which ones AI is genuinely the wrong tool for.
I spend time with the people doing the work, not only the people describing it. Those two accounts are rarely the same, and the difference is usually where the real opportunity is hiding. I follow a process end to end: where the hours go, where mistakes start, what data exists, and what's currently held together by one person's memory.
Then you get a straight recommendation. Sometimes it's "build this one, here's roughly what it costs." Sometimes it's "fix this form and you won't need AI at all." Both are useful answers, and the second one is much cheaper to learn in week two than in month nine.
What you get
- The process mapped as it actually runs, not as documented
- An honest read on whether your data can support automation
- A shortlist scored on value, effort and risk
- What it would roughly cost and how long it would take
- A written note on anything I'd advise you not to do
Typical shape
- 1–2 weeks, fixed fee
- Time with the team doing the work
- Findings walked through with whoever's deciding
02
Build the thing
Scoped tightly, tested properly, and put in front of real users rather than kept in a demo environment.
Everything gets built against your real data from the start. Sample files hide exactly the problems that matter — the scan that's slightly rotated, the field someone filled in with "see email", the supplier whose invoices look nothing like anyone else's.
Before I build, I write the test set: the specific inputs and the behaviour you'd expect from each. That's what "working" means for your project, and it's what I report against — including the cases where it falls short. A good demo proves nothing; a test set you agreed to proves something.
For anything with consequences, a person stays in the loop by design. The system proposes, a human decides, and confidence thresholds control what gets escalated rather than guessed at.
Things I build
- Document extraction and classification
- Assistants over your internal knowledge, with citations
- Workflows that read and write to your real systems
- Triage, routing and drafting inside existing tools
- The test suites that keep all of it honest
How it runs
- Your cloud accounts, your repositories
- Infrastructure as code, documented
- Weekly demos — no surprise reveal at the end
03
Wire it into what you already run
The half nobody wants to pay for, and the half that decides whether any of it gets used.
Most AI work in a normal company is really integration work. The knowledge lives in a shared drive, a CRM with years of inconsistent entry, an ERP nobody wants to touch, and a folder of PDFs somebody maintains by hand. I consolidate what this particular use case needs — deliberately not everything — and get it into a shape something can rely on.
Then it goes where the work already happens. If your team has to open a separate tool and remember it exists, adoption quietly goes to zero. It belongs in the helpdesk, the inbox, the CRM screen they're already looking at.
And the boring safety layer comes with it: who can see what, what gets logged, and how you'd answer someone asking why the system made a particular call.
What this covers
- Working out what your sources are really like
- Cleanup and consolidation, scoped to the use case
- Integrations: CRM, ERP, ticketing, storage, email
- Role-based permissions carried into the AI layer
- Audit logging and decision traceability
One principle
I fix the data this use case needs — not the data warehouse someone might want one day. Holding that line is what keeps a project from turning into an eighteen-month programme.
04
Keep it working — or teach you to
Something nobody owns is something that quietly stops working. Handover here is a deliverable, not a goodbye email.
Models get deprecated. Data drifts. Someone changes a form upstream and accuracy falls off a cliff without anyone noticing for a month. These aren't edge cases — they're the normal life of a system like this, and they're why so many of them are dead within a year.
So I train the people who'll run it, write documentation in language they'll actually read, and leave playbooks for the situations that come up. If you'd rather not carry it in-house yet, I'll watch it on a small retainer instead — quality against your test set, spend per workflow, drift over time, and a short monthly note you can forward to whoever's paying.
Both options are priced before you choose, so I'm not quietly steering you toward the recurring one.
Handover
- Hands-on training for whoever will own it
- Runbooks and architecture documentation
- An internal AI acceptable-use policy if you want one
- Prompts and test sets transferred with the code
Or I keep watching it
- Continuous testing against your set
- Cost and usage monitoring with alerts
- Model upgrades handled before they break you
- A monthly report in plain language
Not sure which of these you need?
That's what the first conversation is for. Tell me what's slow, expensive or error-prone right now and I'll point you at the right starting point — or tell you it isn't me.