Building a Frontend Core Team and Foundations at Razorpay

We partnered with Razorpay's frontend core team—Varun, Kamlesh, Dhruvdutt, Chaitanya, Saurav, and Zameer—to share how we built a dedicated group that enables faster product delivery without compromising quality.

Why Build a Frontend Core Team?

Modern frontend ecosystems have grown exponentially with new tools, frameworks, and patterns, making it a huge effort for individuals to master the stack. Razorpay's engineering team has been expanding rapidly, with the frontend team more than doubling in the past two years, creating a need for focused ownership.

Frontend Engineer Responsibilities

Front of Frontend: Building products, features, UI components, accessibility, micro‑interactions, etc.

Frontend Data: Managing client‑side storage, state, data transformation, API integration.

Frontend Backbone: Setting up build tools, environments, testing frameworks, linting, TypeScript, CI/CD pipelines, and PR checks.

Inspired by Brad Frost’s blog, we realized that a small, specialized team could handle tooling and infrastructure, allowing the broader organization to focus on product development.

Lack of Standardized Infrastructure

Redundant build and deployment work forced individual project owners to dive deep into tooling, leading to inconsistent processes, design variance, complex release management, fragile CI configurations, and insufficient observability.

Legacy Workflow

The previous workflow involved high‑learning‑curve local setups, fragile scripts, and manual steps that slowed development as the organization grew.

Lifecycle of a frontend app in the legacy workflow

Nirnava Workflow

Our envisioned future workflow aims to dramatically improve development efficiency, developer experience, scalability, and performance across all Razorpay products.

Lifecycle of a frontend app in the Nirnava workflow

Our Journey So Far – Laying the Foundations

After identifying cross‑product inefficiencies, we documented gaps, presented challenges and leadership vision, and estimated the cost of current workflows versus potential optimizations.

Document detailed gaps that can be filled in the development workflow.

Show current challenges and our vision to leadership.

Provide cost estimates for time and money spent in the current workflow and potential savings.

We organized the effort into two tracks: Tools & Core Infrastructure and Design System.

Tools and Core Infrastructure

We created a Swiss‑army‑knife set of tools, utilities, and configurations—collectively called Frontend Universe —packaged in a monorepo with clear boundaries.

Packages and modules in the frontend CLI toolchain

Universe‑cli: Scaffolding and composer for all packages.

Universe‑pack: Build chain based on webpack, babel, metro.

Universe‑doctor: Linting, formatting, commit hooks, PR checks diagnostics.

Universe‑test: Unit, integration, and end‑to‑end testing utilities.

Universe‑utils: Shared services such as analytics, A/B testing SDKs, error monitoring, etc.

These modules act like LEGO bricks with sensible defaults and extensible interfaces, allowing product teams to focus on business logic rather than underlying tooling.

Scaffolding a new project using Universe CLI

CLI Scaffolding

Create new projects for Web and Mobile using React or React Native.

CI/CD Setup

Pre‑configured GitHub Actions and Spinnaker pipelines.

Automated Docker builds, Kubernetes configs, and deployment pipelines.

PR checks with DangerJS for automated housekeeping.

Automatic changelog generation and versioning based on change sets.

SSR (Server‑Side Rendering) Support

Code‑splitting, routing, and Redis caching for optimal user experience.

Monitoring / Observability

SpeedCurve and Sentry (with source maps, stack traces, and error severity) for performance and error metrics.

Services and Configurations

ESLint, Prettier, Stylelint for linting.

TypeScript configuration.

A/B testing SDK.

User event analytics SDK.

DangerJS for PR automation.

Monorepo support.

Push notifications for mobile apps.

Security tools such as secretlint.

Common utilities like lodash and date‑functions.

All of these features are available out‑of‑the‑box for new projects and can be plugged into existing ones, reducing migration friction.

Design System

The design system is a set of tools governed by clear standards that ensure consistency across web and mobile, lower the learning curve for consumers, and boost productivity for designers and developers.

Building apps using a cross‑platform design system

Our goal is to create a mature system that streamlines both design tools and developer workflows, resulting in better design/development experience (DX) and ultimately a superior user experience.

Start with an MVP to demonstrate the design system’s value.

Iterate on core principles—color, typography, spacing, borders—before building components.

Phases of the Design System

We also built a Figma plugin that automatically syncs design tokens with the code repository, keeping design and implementation in lockstep.

Principles and Practices

A small autonomous team with an ownership mindset.

Build opinionated tooling with sensible defaults, yet flexible enough to adapt to product needs.

Lower entry barriers by providing pluggable modules and clear interfaces.

Treat the platform as a product and developers as customers; collect feedback continuously.

Prioritize long‑term resilience over short‑term fixes.

Conduct thorough research and early engineer feedback via an RFC process before large features.

evangelize releases, hold demo sessions, and highlight added value.

Educate and empower teams with documentation, migration guides, FAQs, and troubleshooting resources.

Engage with other teams through discussions, feedback collection, and office‑hour consultations.

Identify early adopters, gather their feedback, and use it to build traction across the organization.

Publish guidelines to promote correct usage and cultural adoption.

What Could We Have Done Better?

Spread evangelism earlier; initial focus on core capabilities left internal adoption under‑emphasized.

Avoid assuming product‑market fit from day zero; tools must evolve with consumer demand.

Measuring standardization impact is hard; quantifying efficiency gains and code quality remains a challenge.

Capture engineering pulse via more frequent FGDs and NPS surveys to align priorities with consumer needs.

Recognize and reward contributors beyond the core team to boost internal traction.

Source: https://architect.pub/laying-frontend-foundations-platform-team