Four tiers, in the order that actually works

No — it is closer to an advantage. The hardest part of this work is understanding how the business actually operates, and you already do. My job is to translate that into something a machine can help with, and to explain every decision in language you can push back on.

If you ever leave a conversation with me feeling like you nodded along without understanding, that is my failure and I want to know about it.

You work with me directly. There is no account manager relaying your questions to a delivery team you never meet, and no incentive to stretch a six week build into six months.

The trade-off is honest: I am one person, so I take fewer clients and I will tell you if your timeline does not fit. What you get in exchange is someone who remembers every decision made on your systems.

Not necessarily. For a lot of workflows a frontier model is the right call and the data involved is unremarkable. For others — anything involving customer records, health information, or contract terms you are not free to share — running an open-weight model on hardware you control is the better answer.

That decision gets made per workflow, and the reasoning gets written down so you can take it to a client, an auditor or an insurer.

That is a completely normal outcome and the audit is priced on that basis. The plan is a standalone document you own outright — take it to an internal team, another consultant, or leave it on a shelf until the timing is better.

I would rather you have a good plan you act on later than a rushed build you regret now.

A training session can happen within a couple of weeks. An audit runs two to three weeks. A first custom build is typically six to ten weeks from scope to production.

If someone promises you a production system in days, ask them what happens when it is wrong about something that matters.

It will, occasionally — that is true of your people too. The question is what the system does about it. Every build has explicit boundaries: what it decides alone, what it escalates to a human, and what it does when it is uncertain.

Before anything goes live it is evaluated against real historical cases, so you can see the error rate rather than guess at it.

No. Every audit includes an explicit do-not-automate list, and it is usually one of the most valuable pages in the document. Some processes are too low volume to justify the effort, some carry risk that automation multiplies, and some are the part of the job people actually enjoy.

Roughly five to two hundred people. Below that there is often not enough repeated process to justify a build; above that you start acquiring the procurement and policy layers that made this work so frustrating in my previous career.

If you are outside that range, get in touch anyway and I will be straight with you about fit.