The previous Komodo website was not updated as often as it should have been, and the simple reason (excuse) is that updating it was a task. Somebody had to open the old site builder, find the page, figure out how the layout had been put together, drop in the words, check nothing had moved, and publish. None of those steps was hard. Together they were enough to make “we should write that up” the sentence most often said, and least often acted on.
The new site doesn’t have a content management system in the usual sense, and we’ve updated it more in its first week than we updated the old one in its last twelve months. This is how it works.
Content lives as files, in a design system that does the layout
Every page, case study and article on the site is a text file with a short block of structured data at the top: title, author, date, audience, image. Those files live in version control alongside the code. A schema check runs on every one at build time, so a missing date or a description that’s too long for search results stops the build before it reaches anyone. A second check blocks a short list of phrases we’ve decided not to use.
The design system does the rest. Tom Wood’s brand guidelines were coded into a set of components, with spacing, type scale, and image handling built in. A new article doesn’t need a layout decision. It arrives on-brand because there’s no other way for it to arrive.
The editing tool is a chat
When I want to add something, I open a conversation with Claude and talk it through. It has already read the working memory we keep for the business (the brand rules, the writing rules, the decisions we’ve made and why), so it starts from how we work rather than from a blank page.
Sometimes what I bring is a finished idea. More often it’s a rough one: an idea I’ve just had, or a client result I want to write up. We co-author the piece. I push back on the phrasing, it pushes back on the claims, and it won’t let in a number we can’t stand behind. When the draft is ready, it writes the file, opens a preview at its own web address, and I read it on my laptop and my phone. If I’m happy, it goes live. If I’m not, we go again and tweak till it’s bang on.
This article was written that way. So was the one before it, and so were the case studies you can read elsewhere on the site.
What it doesn’t do
It doesn’t decide what we publish. Nothing goes live without a person reading it in full and saying yes, and for anything that names a client, that person also checks we have their permission. It doesn’t generate the imagery on its own either; those are made separately and chosen by hand against the brand photography. And it doesn’t replace the design team. When the homepage hero needed reworking, Tom did it, because that was a design judgement and he’s the lead designer.
Why this matters more than the build
We’ve written elsewhere about how we built the site. That build was a one-off. This is the part that compounds over time. A website is only ever as good as the last time someone could be bothered to update it, and we’ve taken the bother out.
For a client, the same pattern applies to any product with content: a knowledge base, a help centre, a marketing site, a set of policies. The technology isn’t the hard part. The hard part is designing a system strict enough that a conversation can safely change it. That’s the work we now do for other people, and this site is where we proved it on ourselves.
If you have a product that everyone agrees should be updated more often than it is, that’s a good place to start a conversation.