Why we write our own components instead of using a theme
What a theme gives you and what it takes away, why we build each site's components on our own foundations, and what that means for cost and ownership.
The short answer
A theme is a bundle of someone else’s decisions: layout, styling, features, scripts, made once for a thousand possible sites and sold to each. It includes everything any buyer might want, which means every site carries what it does not use, and it is styled to the theme author’s taste, which means every site that wants to look like itself fights the theme with overrides. We write each site’s components ourselves, on a foundation of components we maintain, test and reuse. The site gets only what it needs, styled from its own design tokens, accessible and fast by construction, and the code belongs to the client. Themes are cheaper on day one and more expensive on every day after: in overrides, in weight, in waiting for the theme author, and in the rebuild when the theme is abandoned. Owning the components means every change is a change to your code rather than a negotiation with someone else’s.
Theme versus own components
| Aspect | A theme | Components built for the site |
|---|---|---|
| What is included | Everything the theme offers, used or not | Only what the site needs |
| Styling | The theme’s, overridden to approximate yours | Yours, from your tokens, from the start |
| Weight and speed | Scripts and styles for unused features on every page | What the page uses |
| Accessibility | Varies; often retrofitted; hard to fix through overrides | Built in at the component level |
| Changing a design | Overrides that fight the theme, and break on updates | Change the component |
| New page type | Whatever the theme supports | Composed from existing components |
| Updates | Risk breaking customisations; may change behaviour | Under your control, tested in your pipeline |
| When the author stops | The site is stranded | Nothing changes |
| Ownership | A licence to use someone else’s code | Your code in your repository |
| Day-one cost | Lower | Higher, reduced by the shared foundation |
| Five-year cost | Higher | Lower |
How we build instead
- Start from the foundation: our tested components for navigation, layout, forms, cards, tables, media, all accessible and fast.
- Define the site’s tokens: colours, type, spacing, from the design.
- Compose the site’s components from the foundation, styled by the tokens, adding only what this site needs.
- Document each component: what it is for, its variants, its accessibility behaviour.
- Test in the pipeline: accessibility, visual regression, performance, on every change.
- Hand over the code: in the client’s repository, with the documentation.
Where themes are fine
A temporary site for an event. A first test of an idea that will be rebuilt if it works. A personal project. Situations where the site’s life is short and its identity does not matter. A business website meant to last five years, carry the brand and be changed as the business changes is not one of those situations.
What this means for you
A theme is cheap to buy and expensive to live with: overrides, unused weight, fragile updates and dependence on an author who may stop. Components built for your site on a proven foundation cost more on day one, less over the years, and belong to you. For a business website meant to last, that is the better arrangement, and it is the only one where every future change is simply a change to your own code.
Frequently asked questions
Is a custom build not much more expensive than a theme?
On day one, somewhat. Over the life of the site, usually not. A theme's price is low because its cost arrives later: every design change fights the theme's assumptions, every page carries the theme's unused features and scripts, every theme update risks breaking customisations, and when the theme is abandoned the site is stranded. Our components start from a tested foundation, so the day-one cost is a fraction of building from nothing, and there is no later cost of that kind.
What do we actually own with custom components?
The code for every part of the site, in your repository, styled from your design tokens, documented, and changeable by any competent developer. Nothing depends on a theme author's continued interest. When you want a section to look different, the change is made to your component; when you want a new page type, it is composed from components you already have.
Do you start from nothing every time?
No. We build on a foundation of components we have written, tested and refined across many sites: navigation, forms, cards, tables, layouts, all accessible and fast. Each site's components are assembled and styled from that foundation for its own design. It is the opposite of a theme: the foundation is ours and proven, and what is built on it is yours and specific.