For business owners
You already tried this.
It didn't work.
Somewhere in your business is a process that's expensive, manual, full of exceptions, and important enough that nobody wants to be the person who breaks it. There's a decent chance you already paid someone to automate it and quietly wrote off the money. That's the normal outcome — roughly 95% of these projects end that way. It's also completely fixable, and the reasons are boringly consistent.
Why it failed last time
Three reasons. It's almost always all three.
They built for the process on paper
Not the one your team actually runs. The real one has forty senders in nine formats, two customers who get special treatment, and a workaround for a system nobody wants to touch. Software built for the tidy version meets the real version on day one and starts producing confident nonsense.
Nobody could tell you how often it was wrong
So “the demo looked good” became the standard for going live. When it started making mistakes, there was no way to tell whether it was getting better or worse — only that people had stopped trusting it.
It was trusted with real decisions far too early
Because the demo went well, not because anything was proven. Then it made one visible, embarrassing mistake in front of a customer — and that killed the project, plus the appetite to ever try again.
Notice that none of those are the AI being bad at its job. They're all failures of method, and method is fixable.
How we'd work
Three ways in. Start with the cheap one.
Almost everyone should start with the audit. It's the fastest way to find out that the process you were certain about isn't the one worth doing.
The Audit
Find out whether this is worth doing at all — before anyone commits a quarter and a budget to it.
What you walk away with
- A map of how the work really happens, exceptions and all — not the version in the process document
- Hard numbers on what it costs you today: hours, money, error rate
- A step-by-step call on which parts AI should touch and which it absolutely shouldn't
- A written plan for how we'd prove it works before you trust it
- A list of what could go wrong, how fast you'd notice, and whether it could be undone
- A ranked shortlist of what to automate first, with the business case for each
The result: A written document your engineers and your CFO can both read, and a defensible answer on whether to proceed.
The Build
Take one process from nothing to running quietly alongside your team on real work.
What you walk away with
- A working system, handling the real process end to end
- All the unglamorous parts: bad input, services going down, duplicate requests, confident wrong answers
- A test set built from your real cases, with an agreed written definition of 'correct'
- A published score — including how often it's wrong and in what specific ways
- Wired into the systems you already use, with strict limits on what it may touch
- Alerts, an automatic shut-off, and written instructions so your team runs it without me
The result: A system running on live work with published numbers, and the evidence needed to decide whether it earns more responsibility.
Embedded
I work as part of your team. More processes, more responsibility earned over time, and I stay on the hook for what I ship.
What you walk away with
- Everything in The Build, repeated across a backlog of processes
- Shared foundations, so each one lands faster than the last
- Ongoing testing as production throws up cases nobody predicted
- Regular reviews of what's earned more freedom — and what's quietly lost it
- On-call for the systems I built
- Your engineers working alongside me, so the capability stays when I leave
The result: A team that can run this loop without me. That's the actual goal.
My side of the deal
The audit is deliberately the cheapest thing I sell, and it's the one most likely to end with me telling you not to proceed.
If two weeks of looking says this process isn't worth automating, I'll tell you plainly and we stop there. You keep the map, the numbers, and the reasoning — which is worth having regardless, because you now know what the process actually costs you.
I'd rather lose the build than take your money for something I don't think will work. The alternative is how you ended up here.
Pricing on request. It depends on the shape of the process and how much of the mess is already known, and quoting before I've seen either would be guessing at your expense.
Working together
What I need, and what you get
Access to the people who actually do the work, not just the people who manage it. Permission to read the systems it touches. One person who can make decisions. And the willingness to hear that a process isn't worth automating.
Everything written down as it happens, not delivered as a slide deck at the end. Systems your team can run without me. And a number behind every claim — if I say something improved, there's a before, an after, and a method.
Nothing I build starts by touching your live process. It runs alongside your team first, recording what it would have done, until the evidence says it's ready. Then it moves up one step — never several.
Every decision the system makes is recorded and reviewable. If it does something surprising in month four, we can go and see exactly why — rather than guessing and hoping.
Next step
Tell me the process that's costing you the most.
Not a discovery call, not a capability deck. Describe the thing that eats your team's week — who touches it, how often it runs, what goes wrong — and I'll tell you whether it's worth fixing. If it isn't, I'll say so.
The specifics are what make a useful answer possible. “We want to use AI” gets you a generic reply from anyone. “Three people spend Tuesday reconciling invoices from forty suppliers and one of them knows all the exceptions” gets you something you can act on.