Why We Rebuilt the Bodkin Website
A new website is often treated as a visual exercise. New typeface, new layout, cleaner transitions, sharper case studies. That mattered to us too. But the real reason we rebuilt the Bodkin site was much simpler: our old one looked good, but it was no longer doing its job.
Over time, especially through our work on CollectivAlly, we became much more aware of the gap between something that appears polished and something that is genuinely usable. The more we worked on accessibility, user journeys and digital product thinking for clients, the more obvious it became that our own site was falling short.
It had served its purpose at one stage. It showed that we care about craft. It created intrigue. It demonstrated that we could design and build something visually distinctive. But it was not especially good at clearly explaining what we do, how we help, or who we help it for. More importantly, parts of the experience were inefficient and potentially alienating to people who simply wanted to understand us quickly and accessibly.
So we rebuilt it.
The problem with making your own website too precious
Design studios are as guilty as anyone of over-designing their own websites.
There is always a temptation to make the studio site into a creative statement first and a communication tool second. We had done exactly that. The result was a site that looked beautiful, but often prioritised atmosphere over clarity.
That trade-off becomes harder to justify when you spend your time helping clients improve conversion, accessibility and usability. At some point, your own site has to live by the same standards.
This rebuild was about correcting that balance. We still wanted intrigue. We still wanted a sense of character. But we also wanted a site that worked harder. One that explained our thinking more clearly, surfaced our capabilities more directly and made it easier for a wider range of people to engage with us.
Accessibility was not a bolt-on
Accessibility was one of the main drivers of the rebuild.
Working on CollectivAlly has changed the way we look at websites. It has made us much more conscious of how many design and development decisions quietly create friction for users. Sometimes that friction is obvious. More often it is subtle: weak hierarchy, awkward focus states, poor content structure, unnecessarily complex interactions, too much movement, inconsistent navigation, vague labelling, or visual ideas that only work if you perceive and interact with the web in one specific way.
That does not mean every accessible website has to be stripped back or boring. In fact, one of the most interesting challenges in this project was asking the opposite question:
How do you make something captivating and expressive without closing it off?
That was the line we were trying to walk. We wanted the site to feel designed, not generic. But we also wanted it to be more robust, more readable, more navigable and more welcoming to a broader audience.
Accessibility is often discussed as a compliance exercise. For us, it is a design quality issue. It forces better decisions. It reveals where unnecessary complexity has crept in. It makes you more honest about whether something actually works.
Why we moved away from Next.js
We still think Next.js is an excellent framework.
We use it regularly and would absolutely still choose it for the right kind of project, particularly for applications and more dynamic products. But for our own marketing site, it had become the wrong tool for the job.
We found ourselves spending too much time wrestling with performance and SEO concerns that should have felt much simpler to manage. Instead of the framework getting out of the way, it often felt like we were having to work around it. Too much of the process became about mitigation, optimisation and edge cases rather than simply building the site we wanted.
That is not a criticism of Next.js across the board. It is more a reflection of fit. For our use case, a content-led studio website, the trade-offs were no longer worth it.
Why Astro made more sense
Astro immediately felt more aligned with what this site needed to be.
Its server-first approach, island architecture and default stance of shipping as little JavaScript as possible made it a natural fit for a fast, content-led marketing site. Astro is designed for content, with features like Content Collections for organising Markdown and MDX with built-in type-safety and validation, and a zero-JavaScript-by-default approach that strips away unnecessary client-side code for faster websites.
That matters because performance is not just a technical metric. It is part of user experience. A faster, lighter site is easier to access, easier to navigate and generally easier to trust.
Astro also gave us a more straightforward mental model. The structure of the site became clearer. The relationship between content, templates and components felt more direct. We could keep interactive pieces where they added value and avoid loading complexity where they did not.
For this kind of site, that was exactly what we wanted.
No CMS, on purpose
One of the more deliberate decisions we made was removing the CMS entirely.
That might sound counterintuitive, especially for a studio site with case studies and journal content. But in practice, a CMS had started to feel like unnecessary overhead for the way we actually work.
We did not need a heavy editorial interface. We did not need the delay of fetching content from a third-party platform. We did not need another service in the stack introducing complexity, maintenance and dependency. What we needed was a simple, reliable way to manage structured content quickly.
So we moved to Markdown files and code.
Astro’s content tooling made that approach feel first-class rather than improvised, and it gave us a workflow that was both faster and easier to reason about.
For us, this is a good example of a broader principle: the best stack is not the one with the most moving parts. It is the one that suits the problem.
The quiet impact of AI on the build process
Another interesting part of this project was how much the role of AI changed while we were building it.
From the beginning of the project to the end, the quality of coding support from large language models improved noticeably. We felt that shift first-hand.
The most immediate use was content management and editing. Working with Claude Code and a file-based content system meant we could update, restructure and refine large parts of the site without the drag of a traditional CMS workflow.
But the bigger impact was creative iteration.
Ideas that would previously have taken hours or days to prototype suddenly became quick experiments. A layout change, a new transition, a content structure tweak, an alternative interaction pattern — all of these became much easier to test. That does not remove the need for judgement. If anything, it increases it. But it changes the economics of experimentation.
Instead of debating whether an idea was worth the effort to mock up, we could often just try it.
That changed the rhythm of the project. It made exploration faster, more fluid and less precious.
Arriving at the design
We went through multiple design directions before landing on the current one.
That is fairly typical, but in this case the process was especially useful because the brief was not simply “make it look better”. The real challenge was to find the right balance between clarity and intrigue.
Too simple, and the site would lose character. Too expressive, and it risked repeating the same mistakes as before.
The direction we landed on feels like the right middle ground. It has enough restraint to let the content breathe, enough structure to support usability, and enough personality to still feel like Bodkin.
That balance is harder to achieve than either extreme.
Choosing FH Dfaalt
Typography played a big role in that balance.
We chose FH Dfaalt, a contemporary sans-serif from Typografische. The foundry describes it as a timeless and universal type family inspired by Breite Grotesk, Akzidenz Grotesk, Neue Haas Grotesk and Helvetica, designed to function as a true default typeface with modern clarity, versatility and precision.
That appealed to us because we did not want the type to perform too loudly. We wanted something with authority and clarity, but without unnecessary flourish. A face that could support the site’s tone rather than dominate it.
In that sense it mirrors the broader intent of the rebuild: less noise, more precision.
What changed in practice
The rebuild was not about chasing a trend or refreshing the visuals for the sake of it. It was about making the site more useful.
That meant:
- clearer messaging about what we actually do
- a structure that better reflects our capabilities across brand, digital and product
- improved readability and hierarchy
- a lighter, more performant frontend
- a more considered approach to accessibility
- a simpler content workflow
- a setup that is easier for us to maintain and evolve
Most importantly, it means the site is now much closer to how we think and work as a studio.
Building your own site is always revealing
Rebuilding your own website is uncomfortable in a useful way.
It forces you to confront the gap between what you say matters and what your own decisions actually prioritise. In our case, it made us rethink how much value there is in simplicity, clarity and restraint when they are backed by strong design rather than used as an excuse for blandness.
The result is a site that feels more honest.
Still designed. Still distinctive. But clearer, lighter, more accessible and more effective at explaining who we are.
And that, ultimately, was the point.
