Step 1: describe the job in one email
Send us a message with three things: what the business is, the job you keep doing by hand or keep putting off, and where the result should land (your inbox, a sheet, a page on your site, a message to the team). A person reads it. You do not need to know what is possible; that is the next step's job.
Good first emails sound like: "Every Monday I spend two hours checking what the three hotels near us charge and writing it up for my partner." Or: "Guests email about dates at all hours and by the time I reply they've booked elsewhere."
Step 2: the scope
We come back with a one-page scope. It names:
- What the automation reads. The sources, by name: a listing, a set of pages, a mailbox, a document you keep, a spreadsheet.
- Which crew runs it. A chief marketing officer with thirteen specialists, a finance crew of analysts, or a specialist written for your job. One of them owns the result.
- When it runs. On a schedule in your time zone, or on a trigger such as an email arriving with the right subject.
- What it produces, and where. A report filed and emailed, a reply sent, a row added, a page updated, an alert raised.
- What it must never do. Who it may write to, what it may not send without a person, what it does when it is unsure.
- What it costs. Stated before anything is built.
Nothing is built until you say yes to the scope. If the job cannot be scoped, that is useful to know early; it usually means the rule is not clear yet, and the fix is a conversation, not code.
Step 3: the build
The automation is written as a mission for the crew: what to read, in what order, what to do with it, and what the finished output looks like. Where a job has phases (find, verify, score, write, send), each phase hands its result to the next and the whole run is one conversation you can read afterwards.
Inputs you own (a price list, an availability sheet, a set of rules) are kept as documents the crew reads at run time, so you can change them without anyone touching the automation.
Step 4: the first month, with you in the loop
For the first runs, every output comes to you before it goes anywhere else. You read it, you reply with what is wrong, and the mission is corrected. This is where the rules get sharp: the edge cases a scope never anticipates show up in week two, not in the planning.
Only when a run has been boringly correct for long enough does it get permission to send on its own, and even then within the rules the scope set.
Step 5: it runs, and you can see it running
Every run is logged: when it started, what it read, which specialist did what, what it produced, where it went. A run that fails says so and says why. A delivery that is refused (a recipient not on the allow-list, say) fails the run rather than quietly sending nothing.
From then on the automation is part of the business. The data it keeps stays current; the report arrives; the enquiry gets its answer. The owner's job becomes reading the output and changing the rules when the business changes.
What this looks like in practice
A weekly market radar for a finance team: seven phases every Monday at 06:00, from recalling last week's ledger to emailing the report, run by the finance crew, with the ledger carried forward inside the report itself so nothing is overwritten.
A grant-matching portal: official sources read on a schedule, every scheme pulled apart into a clean record, versioned, checked by a person, and served live on the site where visitors describe their business and the matches re-rank.
An apartment business: a guest enquiry arrives from the website, an agent checks it against the owner's availability document, replies, and hands the price to the team. In testing as this is written; the label on our Ventures list says so.