React development for portals, dashboards and marketplaces

React is the right choice when the screen behaves like an application: users sign in, work with data, change state and expect the interface to respond instantly. Dashboards, back-office tools, booking flows, portals and the web half of a mobile product all fit. It also has the largest pool of engineers and libraries of any front-end library, which matters when your own team will maintain the code after we hand it over.

It is not always the answer on its own. Public, content-heavy sites that live on search traffic need server rendering, and there we use React through a framework such as Next.js rather than as a single-page app. Enterprise teams already standardised on Angular are often better served by staying on Angular — we build in both, and Bank of Baroda's early-warning system runs on Angular portlets. And a portal that already runs Liferay should usually get React inside it rather than a new front end beside it.

So the first conversation is about how the application is used, who will maintain it and what it has to sit inside — and the recommendation, React or otherwise, is written down with its reasons before anyone starts building.

• Signed-in applications — dashboards, portals, internal tools, booking and checkout flows
• A product that needs web and mobile apps from one team, with React Native
• Screens inside an existing portal or platform, such as Liferay DXP
• A team that will maintain the code and wants the largest hiring pool

Many organisations run a portal that works but looks and feels a decade old. Replacing the platform means re-implementing sign-in, permissions, workflow and content management; rebuilding the screens in React inside it does not. In Liferay DXP, a React portlet or custom element sits on a Liferay page, inherits the user's session and permissions, and talks to the services behind the portal through REST — so the experience is modern and the platform underneath keeps doing its job.

ICICI Bank ran four Java applications with separate logins. As they were consolidated onto Liferay DXP 7.4, the Spring MVC screens were rebuilt as React portlets while the business logic stayed in Java — pages loaded 55 % faster and infrastructure cost fell 45 %. Wipro's employee portal uses React portlets for a responsive self-service experience across more than 50 country-specific sub-portals built from the same standard components; employee self-service adoption rose 75 % within six months.

How the React screens and the Java services behind them are joined — single sign-on, token handling, which logic belongs where — is set out on our Liferay and Spring Boot integration page.

Internal tools are judged by the people who use them for eight hours. They need tables that stay fast with tens of thousands of rows, filters that remember what the user was doing, charts that answer a question rather than decorate a page, keyboard shortcuts, and updates that arrive without a refresh. We virtualise long lists, keep server data in a cache layer such as TanStack Query so screens stay consistent, and push live changes over WebSockets or a real-time database where the work depends on them.

ResqRoute's dispatch centre runs on a React dashboard over FastAPI services, with live GPS positions of every ambulance and traffic-aware routing from Google Maps. In pilot deployments, dispatch response time fell 35 % and real-time tracking replaced 80 % of manual radio communication. The same discipline runs through the analytics and reporting portals we have built for consultancies and agencies, such as Raising iBrows, where automated React dashboards cut campaign reporting time by 70 %.

When a product needs a web app and mobile apps, React on the web and React Native on mobile let one team build both. The two share TypeScript types, API clients, validation and business logic, while each keeps an interface designed for its platform. Features ship to every channel together, and the backend team builds one API rather than one per client.

For MTS, the medical-tourism marketplace, React Native screens share business logic and API integrations with the React web application, which cut front-end development effort by 40 %; the app was localised for five language markets. BizGlobe's travel platform — React on the web, React Native on mobile, one Spring Boot API behind both — went live on web, iOS and Android within a four-month development cycle. Our mobile engineering team builds the native side.

Every project is TypeScript in strict mode, with types generated from the API's OpenAPI or GraphQL schema so the front end and back end cannot drift apart unnoticed. Components come from a shared library documented in Storybook; server data lives in a query cache and only genuinely shared client state goes into a store such as Redux Toolkit or Zustand; forms are validated with the same schema on both sides.

Tests run on every pull request: unit and component tests with Vitest and Testing Library, end-to-end journeys with Playwright, and automated accessibility checks with axe. Bundle size and Core Web Vitals have budgets that fail the build when exceeded, and errors in production are reported with the release and the user journey that triggered them.

• TypeScript strict mode, with API types generated from OpenAPI or GraphQL schemas
• A documented component library in Storybook, built from your design files
• Server state in TanStack Query; Redux Toolkit or Zustand only for shared client state
• Vitest, Testing Library and Playwright in CI; axe accessibility checks on every component
• Bundle and Core Web Vitals budgets that fail the build, and production error reporting

Front ends age faster than back ends. Applications started a few years ago often run on class components, Create React App — which the React team has deprecated — an older Redux setup and libraries that no longer receive updates. We move them to current React with function components and hooks, a Vite build, current routing and data-fetching libraries and TypeScript, one area at a time and with tests written first, so the application keeps shipping throughout.

AngularJS reached end of life in 2021, and many enterprise screens still depend on it or on jQuery. Rather than rewriting everything at once, we mount React into the existing application route by route or screen by screen, share the session and the API layer, and retire the old screens as their replacements go live — the same incremental approach that took ICICI Bank's screens from Spring MVC to React portlets.

Projects start with a short, fixed-fee discovery: the users and their workflows, the screens, the APIs and platforms the front end must sit on, the design system or the lack of one, and the browsers, devices and accessibility level required. It ends in a screen inventory, an architecture, a release plan and a fixed price for the first release.

Cost is driven by the number and complexity of screens, how much of a design system exists, the state of the APIs behind the front end, real-time and offline needs, the number of languages and accessibility requirements, and — for modernisation — how much existing code has to keep running while it is replaced.