Blade: How Razorpay built one design system for every platform

Razorpay processes payments for more than 10 million businesses across India. Its design systems team—three designers and five engineers supported by roughly 70 product designers and 100 front-end developers—owns Blade, a cross-platform design system that spans desktop web, mobile web, iOS, and Android.

The key architectural decision behind Blade is that it exposes the same API and property set across all platforms. Developers who learn the web implementation can carry that knowledge into iOS or Android work without retraining. The team deliberately avoids rebuilding for different platforms, treating a single, unified system as its primary efficiency lever.

Why a common language matters in fintech

Before Blade existed, product teams handled fine-grained UI details in an ad hoc way. Button states, text field error patterns, and other small interactions were frequently hard-coded from scratch. That approach led to repetitive work, missed states, and inconsistent customer experience. Razorpay's position as a financial services provider makes interface consistency especially important: users trust the product with their money, and polish in the UI supports that trust.

Beyond consistency, Blade gives the company a shared vocabulary. Designers and developers reference the same components, which shortens feedback loops and reduces ambiguity during handoff. Design representation in Blade matches what eventually lands in code, so there are no surprises downstream.

Driving adoption across 70-person design and 100-person dev teams

The Razorpay team treats adoption as its hardest problem. Their approach combines several tactics:

  • Leadership alignment: Buy-in is pursued from inception through ongoing funding and team-level usage mandates.
  • Metrics tracking: Internal scripts track project onboarding counts and the percentage of apps built on Blade, which keeps leadership and working groups honest about progress.
  • Direct support channels: Office hours plus a dedicated Slack channel handle consumer questions. An advocacy group, staffed by designers from consuming teams, participates in component decisions and champions Blade inside their own groups.
  • Internal evangelism: New components ship with demo videos and updates to a component status page.

Impact measurement centers on a north star—teams shipping modern, elegant UI with minimal design-system overhead. Razorpay aims for new feature designs to use Blade for 70% of their components; existing surfaces have a lower 50% target. Both design and development teams share this KPI, which keeps them moving toward the same goal.

The team split Blade coverage into two parts. The first is design-phase coverage: designers use a Blade Coverage plugin to measure how much they deviate from the system before code is written. That catches drift early.

Quantitative metrics can't capture the full picture, so the team also runs surveys and focus groups to measure sentiment—whether teams feel faster, whether documentation and training meet their needs, and how collaboration between designers and developers is holding up. All of those measures roll into an annual Net Promoter Score.

The team handles production maintenance with paid customer support, but also with open source CLI workflows on top of GitHub Actions. Internal support Slack channels communicate breaking changes and encourage teams to make upgrades over synchronized release cycles. Adoption is treated as a sustained effort, not a one-time migration: the system ships quarter after quarter, and each new team is onboarded with consistent enablement, office hours, and documentation.

Removing inspection friction with Dev Mode plugins

Handoff used to be a tedious three-step process: developers clicked through Figma layers trying to find the right components, identified each one's props, and rewrote all of that detail in code. A side-project plugin called RazorSharp changed that by auto-generating component code directly from design files, which developers could copy and paste without manual transcription.

RazorSharp worked only for users with edit access to the file—a poor fit for most developers. When Figma's Dev Mode arrived, the team updated the plugin to run inside Dev Mode, which removed the need for edit permissions entirely. The conversion took only two days, because the core functionality already existed.

Dev Mode opened other doors as well. The team now embeds Storybook links on each component, so consumers can jump directly from a Figma component into its Storybook playground. The VS Code extension lets developers see Figma context without leaving their editor. The box model view connects design spacing to CSS expectations, and compare changes/version history give developers a clear picture of what changed in a file between milestones—making it easier to freeze files and avoid timeline slips from last-minute edits.

Token structure & theming after moving to variables

Razorpay is in the middle of migrating from token naming conventions to Figma variables. The shift is already producing measurable workflow changes:

  • Cleaner code output: When copying tokens, developers no longer massage names like surface/text/subtle. Code syntax directives map tokens to friendlier structures—e.g. surface.text.subtle—so copy-paste works verbatim.
  • Spacing tokens now exist: Spacing has long been a common request from consuming teams, and variables finally make it an out-of-the-box deliverable.
  • Light and dark mode without redesigns: Themes are set via variables, not via duplicated design files or modes per component.

The last point notably fixed library bloat. Blade previously shipped multiple components with multiple modes per component—light and dark across payment and banking themes—which caused severe file bloat and slowdowns during design. Collapsing to a single theme backed by variables made the design system's Figma footprint dramatically lighter.

The team reports that 80% of surveyed designers and developers feel more productive using Blade than without it, and credits Dev Mode for a meaningful share of the gains. For teams shopping their own implementation path, Razorpay points to Figma's dev docs for codegen plugins and the shared sample code as starting points.