This article was written by Daria Ryazhskikh, Senior Software Engineer at Bolt.

Bolt is a product company with multiple verticals and independent codebases using different tech stacks for different kinds of front-end:

Native mobile applications for Android and iOS
React Native mobile applications
Web applications — Bolt homepage, internal tools, customer portals and so on

Each vertical works independently with its own teams and practices. Each product has its own UX challenges to serving the needs of millions of people in over 50 countries. Still, we need a unified approach to design:

To keep our products visually consistent
To comply with accessibility requirements
To avoid reinventing the same UI patterns repeatedly
To define common terms for designers and engineers in all teams, for easier collaboration within and between teams

In this article, I’ll describe how our Design System works at Bolt — how it’s structured, what challenges we face, and how we solve them.

(Disclaimer: my experience is mainly from the Android side, in both product and platform teams.)

Structure and ownership

Company-wide solutions can’t rely on individual enthusiasm alone; they need structured ownership and alignment across all roles. And that’s how it works in Bolt.

Actors

Design System Team — Designers who own the design system as a product. Although there are no engineers, their work requires strong technical awareness and a deep understanding of product needs.

Platform Teams — Engineers who own the application foundations: architecture, infrastructure, and best practices per platform. They are responsible for the technical implementation of the Design system.
We have dedicated platform teams for Mobile (Android/iOS), React Native, and Web.

Product Teams — Designers and engineers building product features. They are the stakeholders and consumers of the design system.

Ownership

The diagram below outlines the main layers of our design system, indicating which teams are responsible for each part.

Key pillars

Unified theme

All Bolt products must share the same visual identity. When the branding team changes the accent colour or typography, it should be propagated across all apps quickly and safely, ideally without requiring any effort from the product teams.

There is no out-of-the-box solution for that. Front-end tech stacks are too different, so Bolt designers and engineers built a solution that handles all cases and works seamlessly with our internal tools.

Our approach:

A centralised theme repository (JSON-based), owned by the Design System team. As mentioned, there are only designers, but very special ones. They can define component APIs, support JSONs, and even review platform-specific code in some cases.
Theme export script, owned by the Platform teams to convert the unified JSON to native formats (Android XML, iOS assets, React Native styles, etc)
Theme export pipeline that runs the export script automatically (daily or on demand) and delivers the result to the particular repositories. In the case of Android, it runs nightly and opens a PR to the UIKit library if there are any changes.

The theme is the foundation of the design system. Our theme repository is called `design token`, which reflects its fundamental role. It’s a smart structure that balances flexibility with consistency. Building and maintaining such a solution is a complex technical challenge in its own right.

Design pragmatism

Design should not only look good — it must be implementable with minimum effort.
We deliver quickly, so designers need to understand which UI components already exist, which customisations are safe, and which would require more extensive engineering changes.

Our approach:

We create a comprehensive specification of our UI Kit in Figma, along with a set of implementations for all frontend platforms that we require.

The UI Kit in Figma contains

Component anatomy — internal structure of the component to be considered by the platform engineers while implementing.
API specification — parameters that are accessible for the designers and should be supported in the codebase.
Accessibility guidelines — screen reader instructions, focus and so on, to comply with accessibility requirements.
Usage guidelines — semantics and best practices for the product designers.
Figma components themselves and the variants matching the spec as much as possible
Implementation status per platform — some components may not yet be implemented for certain platforms, and product teams should consider this when planning features.

Examples of the parts of the UI Kit Figma

Anatomy of component ('ProgressBar' component)	API specification	Parameters in Figma playground ('Indicator' component)	Implementation status

UI Kit in codebases — UI components implementation, matching the Figma specification described above. Every UI kit is located in a separate repository and owned by the specific Platform team (Mobile, React Native or Web)

Having clear specifications and implementation statuses ensures that all teams speak the same language — designers understand the engineering progress, and engineers can easily interpret product designs.

Backend-driven UI

As some of our mobile applications are developed for native Android/iOS, they may exhibit misalignments in appearance and behaviour. To reduce this gap — and to accelerate feature delivery — we’re experimenting with a backend-driven UI approach, where the backend defines parts of the interface (or even entire flows).

Our solution is purely engineering-led and has no design ownership, but it is still based on the same design tokens and specifications provided by the Design System team.

Our approach

Common UI model — We reuse the same components defined in the design system, so the natural thing is also to use the same network models when data comes from the backend. Sounds easier than it goes, but we make progress.
Backend-driven layouts — Some screens are rendered directly from backend JSON. Clients support a small set of containers (such as vertical or horizontal stacks) and dynamically place UI elements.
XML-like markup — Even before backend-driven layouts, our backend sent formatted text. We built a custom tag converter that applies colours and text styles aligned with the design system.

Building a flexible backend-driven UI is a challenge that could easily fill a separate article. Its success relies on a solid foundation — precise specifications and well-designed UI components. That’s also why our Figma specs look so technical: they are designed to speak backend language.

Adoption

Even if a technical solution is built, it doesn’t mean it will be used.

We have dozens of product teams for different kinds of frontend, with designers and engineers, having their own projects, priorities, deadlines and established habits. Getting everyone to switch to a shared design system isn’t just a technical migration — it’s a cultural shift, so it requires advocacy across all roles involved in product development.

Design side

Product designers need onboarding to the design system. Sounds not intuitive, but the UI Kit in Figma is a framework that has its learning curve.

What do we do:
Design system team approaches the product designer to advocate the best practices through:

Onboarding sessions
Recurring meetings with product design teams
Qualitative research initiatives to get feedback from the product teams and adjust the components according to the needs of the business

Product engineers often notice incorrect components or colour usages in the feature design and ask the designer to fix it.

Unfortunately, there’s no CI to find the mistakes in the product design automatically. Educating is essential.

Engineering side

Platform teams own the theme export and shared UI components, but are not involved in the feature development.

What did we do in the Mobile platform team (and I personally as Android platform engineer):

Technical meetups — Periodical sessions to explain how things work and advocate the design system usage.
Pipeline checks — Automated CI checks for usage of legacy components, colours or styles. If new violations are found, the Platform team is automatically assigned to such PRs, so they can review and suggest better solutions.

IDE tools — Inspections in Android Studio to suggest migrating old patterns to the new ones. Bulk migration and AI are prone to errors, and manual migration is time-consuming. Inspection is a balanced solution: the quick fix suggests a correct migration, which can be done in bulk, but remains semi-manual and can be applied step by step.
Android Studio inspection suggests to migrate to new component matching text style
Android Studio inspection found incorrect color usage and suggests auto-replacement

Conclusion

What benefit we got from the design system so far:

Faster and centralised updates
Recently, we were asked to change all accent colours across our applications to a new shade of green. Thanks to the Design System, this happened automatically — no manual work from product teams was required. Updating the values in one place and running the theme generation scripts was enough to propagate the change everywhere.
Dark mode support
Several of our apps now support dark mode. The unified theme already includes both light and dark variations, so as long as teams use the theme colours correctly, their products automatically adapt to both modes with minimal effort.
Improved accessibility
We’ve resolved many accessibility issues around contrast and readability. In the past, we lacked clear ownership and a process for this, which caused recurring problems during app reviews. The Design System now handles many of these tasks out of the box, ensuring accessible defaults across all products.
Fewer inconsistencies and reworks
The Design System helps prevent common issues that used to slow us down — like minor, one-off design tweaks that required extra engineering effort or introduced subtle bugs. With shared components and precise specifications, designers avoid making conflicting customisations, and engineers no longer need to fork or override components. As a result, we reduce duplicated work and maintain a consistent UI across our products.
Easier cross-team collaboration.
Designers can now move between teams and verticals with little onboarding — the shared system means consistent tools, patterns, and terminology. For frontend engineers, switching teams still requires learning a new tech stack, but at least the design layer is familiar, and product Figma files no longer need extra explanation.

Building a cross-platform Design System for a large company is a real technical challenge that needs strong engineering skills and strategic vision from the design side. However, it is more than a technical solution — it’s an integral part of a company’s culture of design and development. Building this culture takes time, communication, proper organisation and persistence.

We’ve made significant progress, but the journey continues, and challenges remain.

Join us!

Grow fast, make a global impact, and help make cities for people, not cars. Explore hundreds of open roles on our careers page.

Building a cross-platform design system

We’re hiring!

Recent posts

AI-prototyping: Reality check