Reflections on Bellroy's Tech Team 2025

We shipped more than ever in 2025, and by the end of the year we were struggling with the complexity of it all. In writing this post, I continue to be amazed at the amount the Bellroy Technology Team is able to achieve and support in a year with just 15 staff.

In 2024, we realised our processes had a blind spot. We could see internally-facing projects that were clearly valuable were not getting the attention they deserved, so we revised our project evaluation methodology to give these types of projects fairer weight based on the opportunity cost of not doing them. The result was that, in 2024 and 2025, we split our focus between process automation for other teams, company-wide tooling, infrastructure modernisation and customer-facing features. By the end of the year, a recurring theme in our team retrospectives was that the sheer breadth of what we were maintaining and building had become difficult for any one person to hold in their head, and yet there was an unspoken expectation that everyone was across everything.

Prior to each eight week cycle, we evaluate the list of projects that people all over the business had put forward. Every candidate project goes through a probabilistic NPV model we built internally, which estimates the value each project is likely to deliver over the next five years. The projects described below are the ones that scored highest - and even then, we weren’t always wholly successful at delivering their full value.

What we worked on

Our most complex project - integrating Stripe alongside Braintree as our payment provider - taught us the most about long-tail risk. The project touched every part of our checkout experience and our developers needed to deeply understand our legacy payment flow to be able to implement it as an A/B test. We had a long tail of edge cases that only emerged under real traffic; for example, asynchronous payment types such as AfterPay behave significantly differently in the wild from synchronous payment types, such as a credit card payment. This threw up some edge cases that we had not had to deal with our previous payment provider. Because these issues arose sometimes long after the project was completed, it either fell on the original project team to re-load the context to address the issues or it fell to other personnel to resolve the issue with far less experience with that domain.

Sometimes we understood the business objective and the technical requirements, but hadn’t thought about the staff-facing UX changes. We rolled out more aggressive CloudFront caching across our website, meaningfully improving page load times. While we achieved the desired performance increase, we didn’t sufficiently communicate the change in site behaviour to our content team and they were surprised to discover that their previous experience of “instant publishing” now came with a short lag (while the CloudFront cache was invalidated).

The Technology team have been using AI tools since the early days of Claude Code, and many other teams at Bellroy were buying per-seat licenses for Claude and ChatGPT on a as-needed basis. By mid-year these individual user accounts across ChatGPT and Claude were costing us upwards of USD$3,000 a month. In response to this, we deployed LobeChat as a self-hosted LLM client for the whole company, granting API access to the same models at a fraction of the cost. We ran roadshow sessions and regular open “AI assistance” sessions for the whole company as part of the rollout. Now responsible for keeping the tools up to date for a bigger audience, we were suddenly subjected to the breakneck pace of change in the tool itself and across 3 different model providers.

And those were just the big ticket items - on the customer-facing side, we expanded into new retail partnerships and marketplaces, and enabled bellroy.com orders to be fulfilled via Amazon in more countries. We continued our tradition of working closely with other teams to automate and improve their processes - inbound shipment management for Production, corporate sales inquiries for Wholesale, milestone staff rewards for People & Culture. We undertook a wholesale modernisation of our server infrastructure, migrating our configuration management from Chef to Puppet. We started evaluating Garnix as a replacement for our Hydra CI system, and explored containerisation for our Lambda-based services using Nix’s dockerTools, proving out a model we’re looking to adopt more broadly in 2026.

At the risk of repeating myself - it is staggering to me that a team of this size can achieve so much in a year. I feel very blessed to work with such a great crew.

The cost of doing it all at once

Reading the sections above, it would be easy to imagine these as neat, sequential projects handed off between well-defined teams. The reality was that all of these projects were achieved with teams working in parallel. We had developers rotating between projects every eight weeks based on availability, timezone and skillset. Within a given cycle, developers were focused on a single project - but at each rotation boundary they needed to ramp up on an entirely different system, understand the business context behind the work and build enough mental model to be productive. Over the course of the year, that ramp-up cost compounded.

Coordinating all of this fell disproportionately on a small number of people. The LobeChat rollout, for example, was happening alongside everything else - the roadshows, the support queries, the software updates - and was largely driven by one person (ahem) who was also trying to stay across every other active workstream. We needed to make sure that changes to shared infrastructure didn’t block an in-flight feature (and of course they did, multiple times), that deployments didn’t collide (ditto) and that the groups picking up a piece of work at the start of each cycle had enough context to be effective without lengthy handovers (I’ll give us a solid B+ on this).

By the second half of the year the cumulative weight of all these rotations was something the whole team felt. We got better at writing things down and leaving breadcrumbs for the next group, but the cognitive overhead of supporting this many concurrent workstreams across a team of our size was significant.

Looking ahead

Towards the end of the year one of the team leads suggested we read the Team Topologies book. After reading the book and having many long discussions, we made the decision to start 2026 with a new team structure, categorising our codebases and configuration sets into a “Customer Journey” business stream, an “Operations” business stream or an “Infrastructure” platform team. When we presented this to the team as a potential change, there was a palpable sense of relief and enthusiasm.

This comes at a good time - 2026 is shaping up to be an exciting year for Bellroy, with a fantastic team and an expansion of where we appear in the world and what we’re bringing to our customers. We’ve already seen some benefits with the change to the new structure: better relationships with stakeholders and our developers reporting a much less tumultuous project transition experience. But as with any change, there are trade-offs: our AI tooling and strategy still has no clear owner other than our CTO and there is a stream of work around developer tooling that we don’t currently have the resources to get done. We need to consider further hiring to be able to properly service these work streams.

Who knows, this time next year we might have 16 people!