Home About Services Blog Contact Book a call

Services

Three engagements, one underlying job.

Make the AI in your business dependable, measurable, and cheaper than it is today. Everything below is scoped as a fixed outcome with a written plan, and every one of them can start with a short diagnostic rather than a leap of faith.

Start a conversation Read the common questions
01

AI automation builds

The repetitive, judgement-light work in your business, handed to a workflow that runs whether or not anyone is watching.

Most operational work that feels like it should be automated already is — it’s just spread across a dozen tools, a shared inbox, and someone’s memory. I map that process end to end, then build it as a workflow with real error handling: retries with backoff, idempotent writes, dead-letter handling for the cases that need a human, and logging you can search when something looks wrong.

Where a language model genuinely helps — classifying, extracting, summarising, drafting — it goes in as one step among many, with validation on the way out and a deterministic fallback. Where it doesn’t help, it stays out. A workflow that calls a model for something a regular expression could do is a workflow with a recurring bill and a new failure mode.

Built in n8n when your team needs to read and adjust it without an engineer, and in plain code when the workflow needs to be version-controlled, tested, and deployed like everything else you run.

Talk about this

What You Get

  • A process map of how the work happens today, including the parts nobody documented
  • A working automation deployed to your infrastructure, not mine
  • Error handling and alerting so failures reach a person instead of disappearing
  • A runbook covering what to do when a step fails, and how to change it safely
  • Per-run cost tracking so the economics stay visible as volume grows

You’d Call Me When

  • A team is spending hours a week on copy-paste between systems
  • An existing automation works, but nobody trusts it unsupervised
  • You want an LLM in a process but not a black box in the middle of it
  • Volume is about to grow and the manual version won’t scale with it

Written to be domain-agnostic on purpose. The same structure applies whether the process is claims intake, lead qualification, or supplier reconciliation — the domain shapes the rules, not the engineering.

02

AI infrastructure & cost optimization audits

A structured read of where your AI and cloud spend actually goes, what it buys you, and which changes pay for themselves first.

An audit starts with instrumentation, because most teams genuinely cannot answer “what does this feature cost per user?” I attribute spend down to the feature and the call site, then look at what drives it: model selection, context size, retry behaviour, cache hit rate, embedding churn, and the infrastructure sitting underneath.

What comes back is a findings document with a ranked list of changes. Each one carries an estimated saving, an estimated effort, and an honest note on risk — because some savings cost you quality and you deserve to know which. The ranking is by payback, so you can stop reading after item three and still have captured most of the value.

The deliverable is designed to stand on its own. You can hand it to your own engineers and never speak to me again; that’s a perfectly good outcome and it happens regularly. If you’d rather I implement the top items, that becomes a separate fixed-scope build.

Talk about this

What You Get

  • Cost attribution broken down per feature and per call site, not per vendor invoice
  • An architecture review covering routing, caching, context handling, and retries
  • A ranked remediation plan with estimated saving, effort, and quality risk for each item
  • A reliability read on the failure modes most likely to page someone
  • A live dashboard so the numbers stay true after I’m gone

You’d Call Me When

  • The AI line on the bill grew faster than usage did
  • Nobody can say which feature is responsible for which share of spend
  • You’re about to raise prices or cut scope because unit economics don’t work
  • A board or finance conversation is coming and you need defensible numbers

Scoped to your stack rather than a fixed checklist, and equally applicable to a single flagship feature or a platform with a dozen model-backed endpoints.

03

AI agent & router implementation

A routing layer that sends each request to the cheapest model that can actually handle it — with caching, fallbacks, and agents scoped tightly enough to trust.

Most production traffic is not hard. A sizeable share of requests are short, repetitive, or already answered — and sending all of them to your most expensive model is the most common unforced error I see. A router classifies the request, sends it to the smallest model that clears your quality bar, and escalates only when it needs to.

That requires something teams usually skip: an evaluation set. Before anything gets rerouted we establish what “good enough” means for each request type, measured against real examples from your traffic. Without that, cost optimization is just quality degradation with better marketing.

For agents, the work is mostly about restraint. Tightly scoped tools, explicit termination conditions, structured output that gets validated rather than trusted, budget ceilings per run, and full traces of every decision. An agent that can loop indefinitely against a metered API isn’t an architecture, it’s an open invoice.

Talk about this

What You Get

  • A routing layer with per-request-type model selection and escalation rules
  • An evaluation set drawn from your real traffic, with quality thresholds you agreed to
  • Semantic and exact-match caching where repetition makes it worth having
  • Provider fallbacks so a single vendor outage doesn’t become your outage
  • Tool-calling agents with budget ceilings, timeouts, and complete decision traces

You’d Call Me When

  • One model handles everything, from trivial lookups to genuinely hard reasoning
  • Latency is dominated by a model that’s overqualified for most of the traffic
  • An agent occasionally runs away and you find out via the bill
  • You want to test a cheaper or open-weight model without gambling on quality

The routing rules are where your domain shows up — what counts as high-stakes in a clinical workflow is different from an internal helpdesk, and the thresholds are set accordingly.

Engagement Shapes

How the work is packaged.

Pricing is set per engagement once the scope is clear, and agreed in writing before anything starts. No hourly billing, no open-ended retainers by default.

Diagnostic

One to two weeks

A fixed-fee read of the system: instrumentation, findings, and a ranked plan. Ends with a document and a walkthrough. Most engagements start here, and some usefully end here.

Build

Fixed scope, weekly demos

An agreed outcome, an agreed date, and working software in your repository every week. Scope changes are re-quoted rather than absorbed quietly into a slipping timeline.

Advisory

Ongoing, limited hours

For teams who want a second opinion on architecture and cost decisions as they make them. Deliberately capped, so it stays a conversation rather than becoming a dependency.

Questions

The things people ask first.

How much does an engagement cost?

There’s no published price list, because the useful version of that answer depends on scope. What I can tell you is the shape: most engagements start with a paid diagnostic of one to two weeks with a fixed fee agreed upfront, and builds are quoted as fixed-scope projects rather than hourly. You’ll have a number in writing before any work starts, and I’d rather lose the deal than surprise you on an invoice.

Do you work alongside an in-house engineering team?

That’s the usual arrangement, and the one I prefer. I work in your repository, in your review process, on your infrastructure. Your engineers keep ownership and I keep the specialist load off them. Engagements that end with a team who can maintain the work are the ones that were worth doing.

Do we need to have chosen a model or platform first?

No, and it’s often better if you haven’t. Model and platform choices are downstream of your latency budget, quality bar, data constraints, and volume. If you’ve already committed to something, that’s fine too — I’ll work inside that decision rather than relitigating it, unless it’s the actual cause of your problem.

Can you work within regulated or sensitive-data constraints?

Yes. Five years across Nielsen and Optum means most of my production experience is with data that came with rules attached — access controls, retention, audit trails, and pipelines that had to be explainable after the fact. I’ll ask about your constraints before I propose anything, not after.

What if the honest answer is that we don’t need AI here?

Then that’s the finding, and you’ll get it in writing. Some of the most valuable outcomes I’ve delivered have been replacing a model call with deterministic code, or removing a step entirely. A diagnostic that saves you from building the wrong thing has paid for itself several times over.

How soon can you start, and how do we begin?

Availability is limited on purpose — I run a small number of engagements at once so each gets real attention. The first step is a 30-minute call with no deck: you describe what’s breaking, I ask questions, and we both decide whether there’s a fit. Send a message through the contact page and I’ll reply with times.

Next Step

Tell me what’s breaking.

Send a couple of paragraphs about what you’re building and where it’s straining. I answer every message myself, usually within a business day, and I’ll tell you honestly if it isn’t something I should take on.

Get in touch Book a 30-minute call