The method

Eleven practices for installing
an operation that runs itself.

This is the reasoning underneath the six specialties, published in full and free to use. If you want to take it and build the whole thing yourself, that is a legitimate outcome and everything you need is on this page.

I. Position

01

You are the integration layer

Every tool in the stack was bought to remove work. Each one did, in isolation. What none of them removed is the work of making them agree with each other, and that work quietly landed on the founder or the single best operator in the company.

This is the most expensive labour you own and it is invisible on every P&L. Before automating anything, find the human who is currently acting as the API between two systems. That person is the specification.

02

Automation multiplies an offer, it does not create one

Sending a bad message to four thousand people faster is not leverage, it is a faster way to burn a domain and a reputation. Automation is a multiplier, and a multiplier applied to zero returns zero.

If the manual version of the motion has never converted once, do not automate it. Fix the offer by hand first, with a small list and real conversations. Then make it repeat.

03

Own the infrastructure, or rent your revenue

When an agency holds your sending domains, your enrichment credits and your automation account, they are not holding tools. They are holding your pipeline, and the renewal conversation is not really a negotiation.

Every credential lives in your vault. Every workflow runs in your account. Anything that can reasonably be self-hosted, is. The test is simple: if this supplier disappeared on a Friday, would revenue still arrive on Monday?

II. Design

04

Read the resolver first, not last

When a system misbehaves, the documentation tells you what it was supposed to do and the logs tell you what it actually did. These are different stories and only one of them is true.

Trust the log over the doc, every time. Most of the days lost in automation work are lost debugging an imagined system rather than the running one. Find the code that actually decides, and read that.

05

Delete a tool before adding one

The instinct when a stack is failing is to add the thing that fills the gap. Do that four times and you have a stack that costs more, breaks in more places, and holds four sources of truth for the same customer.

Every new tool must retire an existing one, or justify itself against the integration cost it creates. Consolidation is usually worth more than capability.

06

Every action leaves a trace

The moment a system sends five thousand emails on your behalf, you have inherited the obligation to explain any one of them. If a customer asks why they received a specific message on a specific day, “the AI decided” does not survive contact with a serious buyer.

Structured logs, timestamps and the input that produced each decision are not a later refinement. They are the feature that makes autonomy safe to switch on.

07

Model the unhappy path first

The happy path is the easy half and it is the half everyone demos. The value is in what happens when the enrichment provider returns nothing, when the CRM rejects the write, when the model returns confident nonsense, and when the same lead enters twice from two sources.

A system that fails loudly is worth more than one that succeeds quietly most of the time. Silent failure is the only category that actually costs money, because nobody goes looking.

III. Build

08

One system live beats six specified

Long design phases feel responsible and are usually a way of avoiding the moment where reality disagrees with the plan. Real data breaks assumptions in week one that a specification would have protected for a quarter.

Ship the first specialty into production before designing the second. The second design will be better for it, and you will have seen something work, which is worth more than confidence in a document.

09

Put humans at the money moments

Full autonomy is the wrong goal. The right goal is that a human touches only the decisions where judgement changes the outcome: pricing, a nonstandard reply, anything irreversible, anything reaching a customer for the first time.

Automate the ninety percent that is mechanical and route the ten percent that is consequential to a person with context. Approval should take seconds, not meetings.

10

Write the runbook as you build, not after

Documentation written at the end is a summary of what someone remembers. Documentation written during the build is a record of what actually happened, including the two things that broke and why the obvious approach was rejected.

Every system ships with the plain-language runbook that lets your next hire operate it. If it cannot be handed over, it is not finished, it is working for now.

11

Hand over the keys, deliberately

The end of a good engagement is a transfer, not a dependency. Credentials moved into your vault, repositories under your organisation, workflows in your account, runbooks written, and a session where you drive while I watch.

The measure of the work is whether it keeps running after the relationship ends. Everything else in this method exists to make that the default rather than the exception.

That is the whole method.

The work is these eleven practices applied to your stack, across six specialties, with me in the room while it gets built. Same reasoning, except you are not the one discovering which parts are load bearing.

See the program