The Toolmaker Era
“Never delegate understanding.” — Charles and Ray Eames
The thing most people don’t realise about industrial design is that the beautiful chair is the last thing that happens. Before the chair, there were hours and hours of building tools. These take the form of moulds, jigs, test rigs, custom clamps, tools that exist for no other reason than to let you explore variations in your design. You build a tool to bend plywood at a specific angle. You build another tool to bend it differently.
The tools let you iterate toward something worth shipping. Most of them are built for a single purpose in a single process, never to be used again. The public remembers the chairs, but the practice was building the tools.
This mindset – "what tool do I need to build to achieve the outcome I’m imagining?" – is fundamentally different from the question that has defined digital work for the last two decades: "what tool can I buy?"
The shelf
For almost two decades, starting a business or running a team has meant shopping from the shelf. Shopify or BigCommerce for your store. Campaign Monitor or Mailchimp for your emails. Hubspot or Salesforce for your CRM. WordPress or Squarespace for your website. The shelf was the only viable option, because building custom software was expensive.
But it came at a cost beyond the subscription fees – we stopped thinking like makers. The default question for any business problem became “what already exists?” rather than “what do I actually need?” Over time, the shelf didn’t just constrain functionality, it constrained imagination.
You can see this clearly in how digital design has evolved. Over the last decade everything has started looking the same. Even before Squarespace templates we had Bootstrap making every website look identical, while A/B testing flattened whatever remained. In ecommerce, WooCommerce and Shopify themes meant that thousands of brands with meaningfully different promises and products were delivering nearly identical customer experiences.
The shift
AI coding agents are collapsing the cost of building custom tools to near zero. I don’t mean the cost of building Salesforce. But I do mean the cost of building your tool, for your specific problem.
The loud version of this story has been dominating tech AI-hype headlines. SaaS valuations are dropping as investors question the moats around incumbents if a coding agent can build a CRM in an afternoon. That’s an interesting question, but it’s the less interesting one. The more interesting question isn’t “can I build my own HubSpot?” It’s “what can I build that nobody would ever build?”
The second or third time you catch yourself thinking “it’d be great if there was a tool that did this,” you realise that you can just build it. You are a toolmaker now. Tools for an audience of one. Tools for a team of two. Tools that no startup would ever fund and no SaaS company would ever ship, because the market is just you and your specific context.
The tool
Almost everything you read about AI in business today is about AI doing tasks. Writing emails, analysing data, managing workflows. Agentic all the things!
Most of the tools I’ve built over the last year don’t use AI at all. They’re regular dashboards, workflow views, data tools, that simply weren’t worth building before because the cost was too high. Some of them do use AI, and that’s where it gets interesting and layered. But the AI is a feature within the tool, not the point of the tool.
When I wrote about the takeoff and landing problem last year, the argument was that most AI use ends in copy and paste. The inputs and outputs are text shuttled between a chat window and wherever the real work happens. What I now realise is that building the tools solves the takeoff and landing problem on an individual level. When you build a tool tailored to your context the interfaces just work, because you built them for yourself.
The bulk of my time “using AI” now is talking to Claude Code to get it to build things. Very few text boxes, very little chat, and a very different relationship with AI than the copy-paste pattern.
Some examples…
Last year I needed a different version of our resourcing system at Trout. We use Float, which is fine, but I wanted something shaped to how we actually work rather than how Float assumes we work. So I described what I wanted and Claude Code built it. A bespoke version of an existing SaaS product, tailored exactly to our context. (You can check out a demo of it here)
In January I started using Claude Code to export my record collection from Discogs. I had no plan, just curiosity about what I could build. That turned into a slow process of building an app to explore my vinyl and digital music collection, adding features as I used it and understood what I actually wanted. This is building as thinking, the tool reveals what you need as you use it. It’s still a work in progress, and honestly might never be done as I keep tweaking it (you can try it here).
Then there’s our BD research tool. Trout focuses on founder-led businesses in the home and built environment sector, so there’s high value in knowing what businesses are emerging – who’s growing, who’s funded, who’s building something interesting. I (well, Claude) built a basic version to surface potential clients, used it for a while, then thought it’d be useful if you could press a button on a specific company and it goes and does deeper research. I described that idea to Claude Code and it was built in minutes. That feature does use AI, an LLM goes and researches the potential client in depth. So the tool itself became an AI-powered product, built in a fraction of the time and cost that would have been conceivable even a year ago.
The blandness
There’s a catch, and it connects to what I wrote recently about brands and AI. The same AI that makes everyone a toolmaker also gravitates toward mediocrity. LLMs pull everything toward the average. This is the new version of the Bootstrap/Squarespace problem. If everyone uses AI to build tools and interfaces, everything risks looking and feeling the same again, just a different kind of same.
The toolmaker’s mindset is the antidote. When you’re building for your specific context, with intent and clarity about what you need, the output reflects that specificity. The skill isn’t prompting. It’s knowing what needs to exist and why. It’s taste, the one thing that, no matter how good models get, they can’t learn. An LLM can build you a tool, but it can’t tell you which tool is worth building, or whether the one it built is any good.
This is the difference between vibe-coding a generic dashboard and building something that reflects how you or your team actually thinks and works. The shelf era made distinctiveness hard because everyone was assembling from the same parts. The toolmaker era makes it possible again, but only for those who bring real design thinking to what they’re building.
The tools are the practice
This isn’t “everyone should learn to code.” It’s the ability to look at your work and see the missing tool, to ask the question that designers and makers have always asked: What do I need to build to get where I’m trying to go?
The AI is the apprentice, you’re the one who knows what needs to be built and why
As with all AI right now, this is early and often messy. But this way of working seems to be emerging for people who think like toolmakers, and it will favour smaller, more agile businesses long before it reaches the enterprises still trying to get AI to write their emails. The Eames didn’t outsource their toolmaking to someone else, making the tools was part of the design. The tools are the practice.
- March 2026