Design systems
Tokens, primitives, patterns and documentation, built to be adopted incrementally rather than requiring a rewrite before anything improves.
- Token architecture and theming
- Accessible component primitives
- Living documentation site
Frontend development
Consistency is not a design preference. It is a maintenance cost.
Every interface starts consistent. Then a deadline arrives and someone copies a button, changes one value and moves on, entirely reasonably. Two years later there are fourteen buttons, four of which fail contrast, none of which are documented, and any visual change means finding all of them. We build application front ends and the design systems underneath them, because a design system is not about tidiness. It is about what the next change costs.
AAWCAG 2.2 accessibility target
1Source of truth for tokens
800+Projects delivered
7+Years delivering
How it happens
Four ways a front end decays.
None of these happen in a single bad decision. They accumulate through reasonable choices made under time pressure, which is exactly why the structure has to be there before the pressure arrives.
Component drift
The same element reimplemented slightly differently in a dozen places, because finding and reusing the existing one was harder than writing a new one. Every duplicate multiplies the cost of every future change and quietly guarantees they will fall out of sync.
Accessibility regressions
A component was accessible when it was built, then someone replaced the semantic element with a styled div to fix a layout problem. Without automated checks and a documented pattern nobody notices until a user cannot complete a task.
Bundle creep
A library added for one feature, a date utility nobody replaced, three icon sets. Individually all defensible, collectively the reason the application takes four seconds to become usable on a mid-range phone.
The design handoff gap
The design file says one thing, the code says another, and nobody is sure which is correct. When tokens are the shared source of truth, that argument stops happening because there is only one place a value can come from.
The system
What a design system actually consists of.
The phrase gets used for everything from a colour palette to a full component library. Here is what we mean by it, in the order we build it, because each layer depends on the one before.
-
The foundation. Nothing above it holds without this.
Tokens
Colour, type, spacing, radius and motion as named values with a single definition. Change one and it propagates everywhere, including into the design tool, so the file and the code cannot disagree.
-
Built on tokens.
Primitives
Buttons, inputs, selects, dialogs and menus, built on accessible foundations with keyboard and screen reader behaviour handled once rather than per instance.
-
Built from primitives.
Patterns
The compositions your product repeats: forms, tables, filters, empty states, page shells. This is the layer that saves the most time and is most often skipped.
-
Describes all three, and keeps them found.
Documentation
Live examples with the code beside them, plus the reasoning for when to use each variant and when not to. A component nobody can find gets rebuilt.
Who it is for
Who front-end work is for.
Front-end engineering pays when an interface is large, used all day, or maintained by more than one team. A small product with one designer and two engineers usually needs good components, not a full design system.
Front-end engineering fits
- More than one team or product shares an interface, and it has started to drift.
- A visual change means editing the same element in dozens of places.
- The application is slow to become usable on an ordinary laptop or phone.
- Accessibility has to meet WCAG 2.2 AA for legal, contractual or customer reasons.
- An ageing front end needs moving to a current framework without stopping feature work.
Not yet, or not this
- You have one product, one designer and a small team. A design system would cost more than it returns for now.
- The real problem is the workflow rather than the interface code. Start with UX research.
- The site is mostly content. A content management system will do the job.
What we build
Six areas of front-end work, one system underneath.
Application front ends
Complex interfaces where the difficulty is in state rather than styling: dashboards, editors, workflow tools and data-heavy tables.
- React, Vue and Svelte
- State management and data fetching
- Virtualised tables and large datasets
Accessibility engineering
WCAG 2.2 AA as a build requirement, verified with keyboard and screen reader testing rather than an automated scan alone.
- Keyboard and focus management
- Screen reader testing
- Automated checks in CI
Performance
Bundle budgets, route-level splitting and render profiling, enforced by the build so regressions are caught before release.
- Bundle budgets in CI
- Code splitting and lazy loading
- Render and interaction profiling
Migration and modernisation
Moving a legacy front end forward in slices, with old and new running side by side rather than a rewrite everyone has to wait for.
- Incremental framework migration
- Strangler-pattern replacement
- Design system retrofit
Design to code
Working directly from your design tool so what ships matches what was designed, with the differences resolved before they become defects.
- Figma token synchronisation
- Component parity review
- Visual regression testing
What I found most impressive about them was their ability to combine creativity with a strong strategic focus. … Brilliant Systems's attention to detail, especially regarding UX and functionality, was remarkable.
Read the full review
How we ship it faster
Five times faster, at a fifth of the cost.
Front-end work is one of the clearest cases for AI-first delivery. Component variants, every state a control can be in, responsive behaviour across breakpoints, story files, visual regression baselines and unit tests are all highly patterned and very repetitive. We generate the first pass with AI tooling and put senior engineers on the accessibility behaviour, the token architecture and the review, which are the parts that decide whether the system is still worth using in two years. AI accelerates the work. Our engineers stay accountable for the decisions and the software that ships.
- Component statesDefault, hover, focus, active, disabled, loading, error and empty for every control, generated exhaustively rather than filled in as bugs are reported.
- Responsive variantsLayout behaviour across every breakpoint in your matrix, drafted and then reviewed on real devices rather than only in a browser resize.
- Documentation and storiesLive examples and usage notes written alongside each component, which is the work that otherwise never gets done.
- Test baselinesUnit, accessibility and visual regression coverage created with the component, so the system stays trustworthy as it grows.
An indicative comparison, not a quote or a guarantee. The gain depends on the size of your interface, how much existing code has to move onto the system and how your designers and engineers review work. We estimate every project individually and put scope, timeline and price in writing, with a like-for-like comparison against conventional delivery, before you commit.
Accessibility
Accessibility, done properly.
Automated tools catch only part of what goes wrong. The rest needs a person with a keyboard and a screen reader, which is why we treat accessibility as engineering work rather than a compliance checkbox.
Keyboard first
Every interactive path completed without a mouse, including dialogs, menus and complex widgets where focus management is usually wrong.
Screen reader tested
Real testing with VoiceOver and NVDA on the flows that matter, because a technically valid label can still be useless in practice.
Contrast enforced
Token pairings checked at definition, so an inaccessible combination cannot be assembled from approved values in the first place.
Checked in CI
Automated rules run on every pull request, catching the regressions that a manual audit six months later would find far too late.
Questions we get asked
Starting with whether you need any of this yet.
Do we need a design system, or is it overkill?
If you have one product, one designer and two engineers, probably not yet. It starts paying once more than one team touches the interface, or once you have a second product, or once a visual refresh would mean changing the same thing in fifteen places. We will tell you honestly which side of that line you are on.
Can you build one without stopping feature work?
Yes, and that is how it should be done. We start with tokens and the two or three most-repeated components, adopt them in new work, and replace old instances opportunistically as those areas are touched. A system that requires a freeze to adopt tends not to get adopted.
Which framework should the system be built in?
Whatever your product already uses, in almost every case. Framework-agnostic component libraries sound appealing and usually cost more than they return unless you genuinely run several stacks. If you do, tokens can be shared even when components are not.
How do you keep design and code in sync?
Tokens are defined once and consumed by both, and we run visual regression tests so an unintended change is caught in a pull request rather than by a designer noticing months later. It stops being a coordination problem and becomes a build one.
Our front end is slow. Is that a rewrite?
Rarely. Most of the win is in what you ship rather than how it is written: route-level splitting, removing libraries that are doing very little, deferring work off the critical path. We measure first and give you the ranked list before anyone proposes rewriting anything.
What does front-end work cost?
It depends on the size of the interface, the number of products the system has to serve and how much existing code moves onto it, so we do not publish a price list. Within a week of our first call you get a written approach with a cost and time range and the assumptions behind it, which becomes a fixed proposal with scope, price and milestones when you are ready.
Can you work alongside our designers?
That is the arrangement we prefer. Your designers own the visual language and we own its implementation and its constraints, with tokens as the shared contract. It is considerably better than either side handing finished work across a wall.
What about older browsers?
We agree the support matrix from your own analytics rather than a generic list, then hold to it. Supporting a browser nobody uses is a real ongoing cost, and dropping one that a meaningful share of revenue depends on is worse.
Who owns the system afterwards?
You do, in full. The repository, the documentation site, the tokens and the freedom to hire anyone to extend it. We would rather your team maintains it than that you need us to.
Related services
Next step
Tell us what the next change to your interface costs today.
A senior engineer reads every enquiry and replies within one business day, including an honest view on whether you need a design system yet.
