Read time 4 mins
Author Craig ⚙️
Over the past year, I’ve been leading the rebuild of the Tillo Hub, alongside a broader re-imagining of how we approach front-end applications at Tillo.
I’m Craig Broughton, Senior Front End Engineer at Tillo, and today I want to share what we’ve built so far and where we’re heading next.
At Tillo, we have an application we call the Hub. It’s the central portal for everything Tillo.
The Hub provides features for both Brands and Buyers who integrate with us, supporting transactions, reporting, and a wide range of other capabilities. It also powers internal tooling used by teams across the business to do their jobs effectively.
I’ve worked primarily on the Hub for almost five years, building new features and maintaining the existing codebase. Around two years ago, I started thinking more critically about what a true re-imagining of the Hub could look like, and how we might go about building it. This wasn’t a refresh. The goal was a genuine rebuild, from the ground up.
To support a new Hub and future front-end applications at Tillo, we needed stronger foundations.
The previous Hub had accumulated components over several years, often with different interfaces and patterns. That made reuse harder than it should have been. There was also no single team responsible for component ownership.
As part of the rebuild, we addressed this by creating a dedicated internal component library, with clear ownership and consistent standards. This gives us a reliable baseline and ensures quality remains high as the platform evolves.
Another key missing piece was a token system. Previously, much of our styling was page-specific and often duplicated. The new Hub introduces a dedicated token system that bakes styling directly into components. Engineers can now compose components onto a page and get a consistent, well-designed result with minimal effort.
Together, these foundations give our UX and UI teams confidence that designs can be implemented accurately and consistently.
To maximise knowledge sharing across the company, we deliberately stuck with familiar tooling. We use Vue as our core framework, with Nuxt as the next logical step, across both the component library and the Hub itself.
From day one, we also chose to support capabilities that were either limited or missing previously, including:
This re-imagining represents a significant investment, and there’s still plenty more to come.
The first major output of this work was Pavilion, our internal component library.
Because we weren’t constrained by legacy technical decisions, we were able to design components comprehensively from the start. Each component follows consistent and predictable interfaces, from props and slots to overall behaviour, making them intuitive to use.
Every component is documented in Pavilion, allowing engineers and designers across the business to explore and review it easily.
Alongside Pavilion, we built out the token system.
Tokens define our primitive CSS classes and component-specific styles. Examples include spacing tokens like p-md or colour tokens such as bg-primary. The component library is built entirely on top of these tokens, ensuring styles are reused consistently and remain easy to evolve.
For engineers working outside the component library, tokens provide clear CSS guardrails and remove the need to reinvent styling decisions.
The result is that teams can build new pages and features in the Hub quickly, following our design standards and patterns, often without writing any custom CSS. Tokens also give design and engineering a shared language. When an engineer references a colour or spacing token, design immediately knows what that means.
One of the guiding principles in the original RFC was a modular Hub, where teams could contribute features independently without creating tight coupling.
To support this, we use Nuxt Layers, which allow Nuxt applications to extend other Nuxt applications, even within a single codebase. This lets us structure the Hub around domains. For example, a reporting team can own the reporting area end-to-end, including pages, logic, and domain-specific components, all contained within a single layer.
This approach helps keep responsibilities clear and scales well as more teams contribute to the platform.
While building the foundations, it became clear that we also needed to answer a broader question: how do we build front-end applications at Tillo?
We had a component library and token system, but no consistent way to reuse them across projects.
Within Tillo, engineers collaborate through guilds. As part of the front-end guild, I created a technical roadmap to capture what we’d delivered and what was still missing from a well-rounded front-end ecosystem.
This roadmap reflects where we are today. The next step is an internal CLI that allows teams to spin up new Nuxt applications pre-configured with our best practices, packages, and defaults.
We’ve also improved developer experience with tools like Nix for managing dependencies, and gained better insight into user behaviour through PostHog. Feature flags now allow us to release changes incrementally and safely.
There’s still work ahead, including deeper documentation and A/B testing support, but having this shared view gives the guild a clear sense of progress and direction.
Rebuilding the Hub has been a major milestone for us.
Next up is finalising the Buyer Hub, reaching full feature parity with the existing experience and moving it out of beta. Over time, and once we’re confident, we’ll sunset the existing Hub.
Teams across Tillo are preparing to onboard and start building their own features in the new Hub. The StoreFront team is already doing this independently, and as more teams come onboard, we’ll continue validating and strengthening the system.
Thanks for taking the time to read this. I hope it gives a clear picture of how Pavilion, the token system, and our broader front-end ecosystem are shaping the future of the Tillo Hub.
This work reflects the effort of many people across engineering, past and present, and I’m grateful to everyone who’s helped us get here.
