An automated recruitment firm, built in six days
What build speed changes for a CEO, how to break a business down into tasks, and what has to stay in human hands.
In September, I built an automated recruitment firm in six days. This is not a post about its results. It is far too early, and a firm is judged by its clients, not by how quickly it was put together. It is about something that concerns every CEO: what that kind of speed changes in the way you run a company.
Some context. Since July, I have been building agents on my own, with Claude Code, that take over a growing share of my work as a CEO. In early September, I replaced ten years of financial spreadsheets, 28,719 transactions in all, with a tracker connected to 3 banks. It took one day to build. A recruitment firm is a different scale: not a task, but an entire business. That shift forced me to make my method explicit.
What speed changes for a CEO
For years, building a tool meant a specification, a budget and months of development. Mistakes were expensive, so you thought for a long time before launching anything. When a whole business can be built in a week, the sequence flips: you build, you watch what happens, you correct.
Today, a company can be registered in a matter of days. Building the operations behind it used to take months. That gap is closing, and it changes three things for you.
Technology is no longer the bottleneck. The question is no longer "can we build it?" but "do I want it?". Which offer, at what price, under which rules, and when to stop: these are decisions, and they sit with you. The faster things get built, the more your ability to decide sets the pace of the company.
Experiments get cheaper. Attention does not. Building fast also means you can be wrong fast. Before you build, write down what will tell you it works, and the point at which you will stop. Without that, you end up with tools that keep running while nobody knows whether they help.
Build speed does not speed up the market. A system can be ready in six days. Clients, candidates and teams still move at their own pace. Speed does not change that, which is why I draw no commercial conclusion from those six days.
Breaking a business down into tasks
A business is not one block. It is a sequence of actions that people repeat every day, usually without ever writing them down. The real work happens before any building: writing those actions down, one at a time.
For each task, I ask the same five questions.
| Question | What it settles |
|---|---|
| What triggers the task? | A schedule, an incoming message, a threshold being crossed |
| What does it need? | The data, and where that data lives |
| What does it produce? | A message, a document, an update |
| Who signs off? | Nobody, a team member, or you |
| What happens when in doubt? | Who it goes to, and how fast |
Then I sort every task into one of three families.
- Mechanical tasks: moving data, sending a document, updating a sheet. No AI needed. Plain automation does the job and costs almost nothing per run.
- Reading and writing tasks: sorting messages, summarizing a thread, drafting a first version, reconciling two figures. This is where AI earns its place, because a text has to be understood or produced.
- Decisions and relationships: choosing, negotiating, delivering bad news, making a commitment. These stay human.
Every task in the first two families goes to an agent: written instructions plus a schedule. For each agent, I also write down what must be escalated to a person. An agent without an escalation rule will eventually do something nobody decided.
This breakdown works for any service business, whether you run a trading company, a services group or a family holding. Do it on yours and you will probably find that a large share of the work falls into the first two families. The third is where you want to spend your time.
What stays human
Automating a business does not mean nobody answers for it. Whatever the business, four things stay with people.
- Setting the rules. A system applies rules; it does not choose them. The offer, the price, what the system may say or promise: that is your call.
- Checking before launch. Before a system acts on its own, review what it produces on real cases. You do not launch blind.
- Owning what goes out. A message sent in the company's name commits the company. The fact that an agent drafted it changes nothing about who is responsible.
- Handling exceptions. Whatever the rules did not foresee goes to a person. Handling those cases is also how the rules get better.
What I take from those six days fits in one sentence: the more the machine does, the more what is left to the CEO matters. And what is left is the essential part: deciding.
Key takeaways
- Build speed shifts your job: fewer specifications, more decisions.
- Break the business into tasks before talking about tools: trigger, data, output, sign-off, escalation.
- Keep AI for tasks that involve reading or writing. Plain automation handles the rest.
- Before you build, write down what will prove it works, and when you will stop.
- Building fast does not guarantee the market will follow. Judge on results, not on speed.