Over the last year, Komodo has changed shape. A lot. We are repositioning as an AI partner to organisations we work with, and we have re-engineered how we deliver: a five-step way of working with clients, from a free briefing session through discovery and build to a twelve-month aftercare agreement, and two ways to engage us, either as an AI partner or for AI-accelerated design and build. Behind that sits a different way of running the studio, with AI doing a large share of the construction and senior people doing the thinking. It has been a significant business pivot, and the brand refresh that followed was the visible part.
The website we were running described a company that no longer really existed. It was built in a no-code tool; it said nothing about the ladder or the partnership model, and it didn’t communicate the way we design and build things now. If we were going to tell clients that a small senior team with AI can deliver what used to need a full project team, our shop window needed to reflect this.
Who did what
The brand came first, and it came from people. Tom Wood and the design team produced the new guidelines by hand: a monochrome palette with no accent colour, PolySans and Space Grotesk, a four-variant grid, and the rule that colour only ever comes from client work and imagery. None of that was generated.
I led the build. I have built websites before (granted, a long time ago, but let’s not dwell on this), and I have spent two decades working alongside design and development teams, so I knew what good looked like and I could tell when the work in front of me was wrong. That ultimately mattered more than having technical chops.
The AI (Claude, in our case) did the construction, and before we went live it also ran a full adversarial review of its own codebase, the kind of audit we would normally commission from a senior engineer. My job was to read that review and decide what to act on.
Removing the friction
Anyone who has used an AI coding tool knows the frustrating version of this story. It writes something plausible, you explain why it is wrong, it writes something else, and you go round again. It can get frustrating fast as it constantly doesn’t quite ‘get it’.
That is not what happened here.
The difference was what the AI had read before it started. We have built a working memory for the business: a written, structured account of how Komodo works, covering the brand guidelines, the writing rules, the phrases we don’t use, the decisions we have made and the reasons behind them, who does what and who to ask.
We set up the first version of this quickly, and it has evolved since. We update it as we go every day, because the AI works alongside it every day. So when it drafted a page, it already knew that colour comes from client work, that we don’t use hype words about ourselves, and that a claim without a number behind it doesn’t go on our site. The nuance that normally arrives through rounds of correction was there in the first draft.
It is easy to underestimate how much of a project that kind of nuance is. Most of the time a new team member spends getting up to speed is not learning the tools. They are learning the hundred small preferences and past decisions that nobody wrote down. We write them down in a system that tracks conversations and decisions across multiple channels (email, Slack, meetings, etc.) in real time, so a coding assistant with that access behaves more like a colleague in their second year than one on their first day.
I helped Tom set the same structure up on his machine. He is a designer, and he doesn’t normally write code as part of his role. He shipped multiple pull requests to the site himself, including the homepage hero he was not happy with. That, more than anything I did, convinced me the speed comes from the way of working rather than from the person at the keyboard.
Working with it as a colleague
Most of the work was conversation, and I came to think of the AI as a colleague rather than a tool. I would describe what I wanted, sometimes clearly but often as half-formed ramblings of an idea straight out of a meeting, and it would propose an approach. Then we would argue about it and refine it. It pushed back on claims it could not evidence, and several lines I would happily have published were cut because neither of us could point to the proof. I pushed back on structure, priorities and taste.
When the enquiry form design assumed a database was the correct solution, one question from me, “do we need one?”, replaced existing architecture with something simpler and cheaper. It had not thought to ask but the end result was better.
Tom rejected a hero image on sight and reworked the composition himself. I vetoed a colour. We drafted every line of copy together and a person signed off on it.
It did the volume. It extracted the brand tokens from Figma and turned them into a coded design system, 58 components at the last count and still growing as Tom adds to it. It ported 51 archive articles and 20 case-study records into structured content with a schema that refuses to build if a fact is missing or a banned phrase creeps in. It mapped the 227 URLs on the old site to 147 redirects so we didn’t lose anything we’d earned in search. It wrote the serverless functions behind the enquiry forms, including a step that reads each enquiry and pings me in Slack. Each time it ran adversarial reviews on its own code before anything got merged.
What it took
Nobody came off client work, and no budget was set aside. The site was built in the gaps around running the company, mostly outside office hours, and it went from a blank repository to the live domain without ever becoming a project on the studio board. That is the part that matters. A studio our size has never been able to give its own website that kind of attention without taking it from somewhere else, and the only reason it could this time is the way the AI was working alongside us.
The value delivered
We are not claiming the AI built the whole website. A designer crafted the brand, an experienced team directed and checked the work, and an AI trained on how we work did the construction.
The images are around 87% lighter than our own first build; the site is built to WCAG 2.2 AA from the start, and every page carries structured data so it can be found by the AI search engines our clients increasingly reach us through. Those are the numbers. The rest you can judge by looking around.
What matters for anyone else is that none of this depended on the website being ours. The same three ingredients apply to a client’s product: people who know the domain and can tell good from bad, an AI that has been taught how that organisation works before it starts, and a way of working where the two argue it out in the open. Take away the second ingredient, and you are back to the frustrating version of the story. Take away the first, and you have something fast that nobody should trust.
The structure we taught the AI, and the process and tooling wrapped around it, are not a one-off for this project. They are built, they work, and they are what we now bring to client work. This site is what it looks like when we do it to ourselves.
There is a second half to this story, which is how the site gets updated now that it is live. That has changed more than the build did, and it is the subject of the next article. If you are wondering what the same way of working would do for a product you already run, the way in is a short conversation.