Build the machine, not the thing
Think of him what you will, but Elon Musk likes to say that the factory is the product, that the real work is building the machine that builds the machine. I used to think of that as something for car companies. Lately it’s how I work on almost everything, at a much smaller scale.
When I need something made, my first question is no longer how to make it. It’s how to build something that makes it.
A machine for one video
A while ago I needed to make a video for a client. Instead of sitting down and editing it by hand, I built a small video machine made for that one video. It sounds like a detour, and it isn’t. Once the machine existed, every change was something I could ask it to redo instead of something I had to redo myself.
That was the first time I noticed the shift. The video was the output, but the machine was the work.
An ad machine for TikTok
Then I needed a lot of ads for TikTok. So I built an ad machine.
It starts with research. It looks at what’s trending on TikTok right now, learns about the brand the ads are for, and pulls in what’s known about what makes short ads convert. From that it writes scripts for all the videos. Then it renders every one of them with AI.
The last part is my favourite. I built a little TikTok player of my own, so I could scroll through the ads the way someone would on their phone and like the ones that worked. The ones I liked, I exported and uploaded as ads on TikTok.
My job in that process wasn’t making ads. It was deciding which ones were good. The machine did the volume and I did the judging, which is the part I’m actually useful for.
How I work now
I do this all the time now. For anything I want to do, I ask what the most efficient way to do it would be, and more often than not the answer is to build a tool or a machine that does most of the work for me.
A machine is also something I keep. The next video or the next campaign doesn’t start from scratch. It starts from the machine, which gets a little better every time I use it.
This only works because building has become cheap. AI writes most of the code, and a new machine often takes an afternoon. A few years ago a custom tool for a single video would have been absurd. Now it’s often the quickest way to get the video done.
Build or buy, again
Companies have argued about build or buy for as long as there has been software. For most of that time, buy usually won. Building was slow, expensive and risky, and someone else had already solved your problem well enough.
I think the time is very ripe for build. I touched on this in my field notes, and I’ve only become more convinced since. Almost anything can now be built quickly and at a low cost.
For a big company, that means a lot of the software it buys could be replaced. Subscriptions, licences per seat, enterprise deals with yearly price increases. Much of it could be swapped for something built in-house that costs a fraction, even with a developer on staff to maintain it. And it would fit the company better, because it’s made for how that company works instead of how a vendor imagined thousands of companies work.
Not everything, of course. Payments, email delivery and the systems where a mistake is expensive are still worth buying from people who do nothing else.
Some products also have a moat that cheap code doesn’t touch, because they get better from everyone else using them. You won’t build your own large language model, at least not for now. It costs a fortune to train one, and the best models keep improving from enormous amounts of data and use. The same goes for a social network. However cheap the code gets, the value is the people who are already on it.
But for most of what a company pays for, the default has moved. “Can we build this?” used to be a serious question. Now the more interesting one is “why are we still paying for this?”
Machines that talk to each other
The bigger reason to build is what happens when you have several machines.
Bought tools are islands. Each one has its own data, its own logins and its own idea of how things should work, and connecting them is a project in itself. Tools you build yourself can share the same data and the same rules from the start. The output of one machine becomes the input of the next.
That’s how you end up organising around AI instead of putting it on top. You build one machine, then another that feeds it, then one that takes over the step after. Each one solves a real need on its own, and together they start to cover more and more of how the business runs, automating it one part at a time.


