Blade: Razorpay's design system, open for reuse

A design system with a governance layer, not a component gallery

Blade is the design system that powers Razorpay, and it is published under the MIT licence, which is the first thing to check for a company design system because most of them are not open at all. The predecessor package, @razorpay/blade-old, is listed as deprecated and private, so the current repository is the first public release of the system.

The four features listed in the readme are the ones that make it more than a component set. It is cross-platform, working natively on React Web and React Native from the same codebase, which is the hard part of a shared design system and the part most teams give up on. It supports white labelling through a theme playground, so the same components can be re-skinned for a different brand. It is accessible, with a manual testing document in the repository under rfcs. And it has documented RFCs and API decisions, with the decisions file for the Alert component shown as an example of where component-level API reasoning is recorded.

That last item is the strongest signal about the project's character. A design system that records why an API is shaped the way it is, in the repository, is a system with a maintainer who expects to explain decisions and expects contributors to follow a process. It also means the history of the design is inspectable, which is worth more to an adopting team than the component count.

The primary language is TypeScript, the default branch is master, the homepage is blade.razorpay.com, and the docs link points to a guide for installation and to the site itself.

Eight packages, and what each one is for

The monorepo is organised as a set of packages that together make up the ecosystem, and the table in the readme is more informative than a component list.

The blade package is the core design system, with cross-platform UI components for React Web and React Native. The blade-plugin package is a Claude Code plugin with cross-agent skills and the Blade knowledgebase, described as the source of truth for AI documentation. The blade-mcp package is a Model Context Protocol server for AI-assisted development using Blade components, and it is in maintenance mode.

The three Figma-side packages are the unusual part. plugin-figma-blade-coverage measures Blade component usage and coverage in design files, and the readme describes it as acting like a linter for design files. plugin-figma-token-publisher publishes design tokens. And widget-figma-dev-handoff-checklist is a Figma widget for design-to-development handoff checklists.

There are two more that are not Figma. blade-coverage-extension is a browser extension for measuring Blade component usage, which is the same idea as the Figma coverage plugin but on the running application. And eslint-plugin-blade is an ESLint plugin for enforcing Blade coding standards.

The two together are the interesting combination. The Figma plugin tells you which components your designers actually use, the browser extension tells you which components your developers actually ship, and the ESLint plugin stops the wrong thing being written in the first place. That is design system governance expressed as three tools rather than as a process document.

The root package.json adds to the picture. The workspaces list names packages/blade, packages/blade-core, packages/eslint-plugin-blade, packages/blade-mcp, packages/blade-svelte and packages/blade-plugin, with a nohoist entry for @razorpay/blade/** so those packages are not hoisted to the root node_modules. There is a lerna.json, a .changeset/ directory for version management, a yarn.lock, and a rfcs/ directory at the root.

The repository tooling, which shows how the system is maintained

The root package.json is private, version 0.0.1, requires Node 18.12.1 or newer, and its scripts are the clearest available picture of the maintenance workflow.

Type checking is per-package and scoped through lerna, with tsc:blade running the typecheck for @razorpay/blade. Then there is a pair of scripts that have no equivalent in most component libraries: tsc:knowledgebase, which runs a lint over the knowledgebase through scripts/lintKnowledgebase.js, and check:knowledgebase-drift, which runs scripts/checkKnowledgebaseDrift.js. The names say what they do. The knowledgebase that the AI tooling reads is linted, and a separate check verifies that the knowledgebase has not drifted away from the code.

That drift check is the single most interesting script in the file. A design system with an AI knowledgebase has a failure mode that a normal component library does not have: the documentation of the components goes stale, and an assistant reading a stale knowledgebase will confidently recommend an API that no longer exists. Automating the detection of that is a sign the maintainers understand the problem they created by making the docs machine-readable.

Linting is per package as well, with eslint over js, jsx, ts and tsx plus stylelint, and each package has its own lint and lint:fix variant. The blade-mcp lint runs with NODE_OPTIONS set to a maximum old space size of 8192 megabytes, which is a small detail that tells you the MCP server's lint pass does not fit in a default Node heap.

The tree also carries a .semgrepignore, a .codesandbox/ directory, a .cursor/ directory, a .claude/ directory and an .agents/ directory, plus AGENTS.md and CLAUDE.md, so the repository is set up for both human contributors and coding agents. There is a CODEOWNERS file, a .design-sync/ directory and a scripts/ directory.

White labelling and cross-platform rendering, side by side

Two of the design system's claims carry most of the engineering weight, and they are the ones a adopting team should test hardest.

Cross-platform rendering from one codebase is the harder of the two. React Web and React Native have different primitives, different layout models and different accessibility APIs, so a component that is genuinely shared has to be written against the intersection rather than against either platform. The readme states that Blade works natively on both, and the packages list includes a blade-svelte package as well, which suggests the component logic is separated from the rendering layer per platform rather than shared wholesale.

White labelling is the other one. The readme points at a theming and theme playground guide, and the fact that Razorpay is a payments company explains why this is a first-class feature rather than a nice-to-have: a payment provider is frequently embedded into a merchant's own product, and the merchant's brand, not Razorpay's, is what the customer should see. A design system that cannot be re-skinned is unusable for that business model, so theming here is a product requirement rather than a design-system nicety.

The accessibility claim is backed by a document rather than a slogan. The link points to an RFC file about manual testing, which is a more useful artefact for an adopter than a compliance badge, because it tells you what was actually checked.

What is not visible in the visible documentation is the React and React Native version range the components support, the bundle size of the core package, and the list of components. Those are in the documentation site rather than the repository readme, and they are the three things to look up before committing to a dependency.

Where Blade is the wrong choice

The first limitation is weight. A full design system with a theming layer, cross-platform rendering and an ESLint plugin is a large dependency for a project that needs a date picker and a modal. If your requirement is a few accessible controls, a headless component library with your own styling is less code to own and less to keep in step with the upstream release cadence, which for Blade is 12.129.0 and rising.

The second is that a design system carries opinions you did not choose. Blade is the system Razorpay uses, so its components encode Razorpay's decisions about spacing, tone, and which patterns are correct. Adopting it means adopting those decisions, and the white labelling layer can change the surface but not the structure. A team with an existing design language has to decide whether to conform or to fork.

The third is the React Native commitment. The cross-platform claim is a strength when you ship both, and a liability when you ship only web, because you are then depending on a library whose components are partly written for a platform you do not target.

The fourth is the AI tooling. The knowledgebase, the drift check, the Claude Code plugin, the MCP server and the agent-oriented directories in the tree are all recent additions to a system that predates them. They are useful, and they are also a moving surface. The MCP server is explicitly in maintenance mode, which suggests the fast-moving parts are the ones most likely to change shape, and the drift check exists precisely because that surface can go stale.

The fifth is that the design-to-code handoff tooling is a bet on Figma. Three of the eight packages are Figma plugins, and the coverage and handoff workflows assume your designers work in Figma and that their files are the source of truth. A team that designs elsewhere gets none of that value and still inherits the dependency.

The sixth is governance overhead. RFCs, API decision records, CODEOWNERS, changesets and a drift check are all signals of a process with real weight. That process is what keeps a design system coherent across hundreds of contributors, and it is also a process a small team now has to participate in if it wants to contribute back.

Editorial conclusion

Blade fits a team that wants a design system with the governance that comes from it, since the repository carries documented RFCs, API decision records, an ESLint plugin that enforces the coding standards, an Figma coverage plugin that measures component usage in design files, and a knowledgebase that AI tooling reads. It is the wrong choice for a project that only needs a handful of accessible form controls, and it is a heavy dependency for a small team. Before adopting it, read the installation guide and the theming documentation, check the peer expectations for React and React Native, and note that the last push was on 2026-10-20 with @razorpay/blade at version 12.129.0 published on 2026-10-07.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. razorpay/blade on GitHub
4. README
5. Releases