When most people think about a website, they think in pages. A homepage, an about page, a case study. That's what they see, and it's a natural way to think about it. Our challenge, as designers and developers, is to think past that. Not in pages, but in the building blocks those pages are made from.
Buildingblocks,notpages
A component-based approach starts from a different assumption. Rather than designing and building pages, you design and build the elements that pages are made from. A heading. A card. A media block. A testimonial. A call to action. Each one defined once, with its own rules for spacing, typography, colour, and behaviour. Pages are then assembled from those elements, rather than built individually from scratch.
The analogy to a design system is direct and deliberate. A component library for a website is the same kind of thinking as a design system for a brand. It's not a shortcut or a technical convenience. It's a way of encoding decisions so they hold up at scale, whoever is working with them.
This is why we build every site this way. Not because it's the fashionable approach, but because it's the one that protects the design over time.
Whydesignersneedtothinkthiswaytoo
This is the part that matters most, and the part that's most often left out of the conversation.
A component architecture works best when the design is conceived the same way. When a designer approaches a project by defining the building blocks first, and then assembles pages from those blocks, the handover is cleaner, the build is faster, and the result is more coherent. When a designer works page by page, each one slightly different from the last, the build team either has to rationalise that into a system (which takes time and involves judgement calls that should have been design decisions) or build it literally, which produces something that's expensive to maintain and difficult to extend.
The best projects we work on are the ones where the design team is already thinking in components. Where there's a considered set of elements, a clear sense of how they combine, and an understanding that the system is the product, not just the pages.
That conversation is most valuable early. Before the design is locked, when there's still room to make decisions about how elements relate to each other rather than retrofitting a system onto work that was designed without one.
Whatthismakespossible
Consistency
When components are defined once and reused everywhere, design decisions are enforced by the system rather than by whoever happens to be editing the site. Typography scales correctly. Spacing is consistent. Colours are applied as intended. The design doesn't depend on discipline; it depends on structure.
This matters most when content is being added by someone who wasn't involved in the original design. A well-built component library makes it difficult to break the system accidentally. The guardrails are built in.
Scale
A template-based site gets harder to manage as it grows. More templates, more exceptions, more inconsistency. A component-based site scales in the opposite direction. New pages are assembled from existing elements. New sections can be added without a redesign. The system absorbs growth rather than resisting it.
For a client who's launching a site and expecting to build on it, this is the difference between a site that feels coherent at fifty pages and one that starts showing cracks at ten.
Growth and evolution
Sites need to change. Brands evolve, priorities shift, new products get launched. A component architecture makes that possible without starting from scratch. New components can be added that feel native to the original design language. Existing ones can be updated across the whole site at once. The site can grow up without being rebuilt.
This is what we mean when we say this approach is about systems thinking. It's not a technical preference. It's a way of building something that was designed to last.
Whatitlookslikeinpractice
At the start of a project, we work with the design team to define the component set together. What are the core building blocks? How do they behave at different sizes? How do they combine? What flexibility does each one need?
Those decisions shape everything that follows. The build is faster because the system is clear. The CMS is structured around the same components, so what editors see reflects how the site was designed. And when the project is finished and the client takes ownership, they're working with something coherent, not a collection of one-off pages held together loosely.
It's a more considered way to start. It's also the reason the sites we build hold up.
