How I work

The method is the same on every engagement, whatever the client. It exists because most AI work fails in the last mile, not in the demo.

One workflow first

Start with one repeatable workflow that wastes a person's time. Prove it works in production, with its own success criteria, before touching a second one. Scope widens only after the first one is measured.

Success criteria before the build

Before any code, the job is written down: what enters, what comes out, what "done" looks like, what evidence proves it, and where a person must remain in control. Changing this costs a sentence now and a rebuild later.

The server enforces the process

The systems do not rely on the AI behaving. The process lives in a server, and the server refuses what the process forbids:

• out-of-order work (code before the design documents exist)
• placeholder text, secrets and wrong-stack files, rejected at the moment of writing
• self-reported scores, recomputed on the server instead of trusted
• claims without evidence, and quantities without a number
• any edit after approval, which voids the approval until the checks run again

This is what makes a system safe to hand to a business without a person watching every step.

Humans sit at decisions, not at the keyboard

The person's job is to decide, not to type. In a typical run the human steps are the brief, the design approval and the go-live. Everything between is executed and checked by the system. High-impact actions always keep a human gate, agreed before deployment.

Counted, not guessed: the 70%

"70%+ automated" is a count, not a slogan. One real website-delivery run has ten steps:

Seven of ten steps need no human: 70%. The three human steps are decisions.

That is a today figure: this workflow is built and running. Before it existed the same run was 0% today and 70% could be, because seven of those steps were a person prompting the AI through the work. Both numbers are defined on count your own workflow, and any other workflow is counted the same way during the audit, with the numbers agreed before anything is built.

State lives outside the chat

An AI's context window fills up and resets, and then both the developer and the AI lose the thread. So every build has an identifier and its state lives in a database, not in the conversation. A new session resumes from the last completed step instead of re-explaining the project.

Evidence over claims

Every number carries its date and its source. Client outcomes are published only when verified, and never sold before they can be delivered. The journey in numbers is the model: each count, where it came from, and how it was made.

What I refuse

• A demo with no path to production
• Invented statistics or rounded-up results
• Publishing the internals of a client's or a company's systems
• Automating a decision that should stay with a person

The engagement, in four moves

1. Audit. Map one workflow step by step, count where the humans sit, find the highest-value automation point, define success.
2. Pilot. Build one limited workflow with the integrations, approvals, logging and evaluation it needs, then hand it over.
3. Production. Connect the live tools, set permissions, test the failure paths, document, prepare the team.
4. Optimize. Review failures, improve the evaluations, extend only what proved useful.

Each stage earns the next. Start with the audit.