Skip to content
Muhammad Vohra.
Selected work

Rightmove · Reporting platform

Lead Reports Rebuild

Replacing a reporting experience that timed out on large lead datasets.

Client
Rightmove
My role
Independent owner of the frontend: architecture, data flow, permissions, testing and phased rollout.
Lead reports · Harbourside Estates (fictional)

Loading interactive demo… Change the date range, switch the chart view, hover the bars, search and filter the table.

Illustrative interactive demo with synthetic data, created to demonstrate the project. Not a screenshot of production software.

Context

Rightmove's customer reporting experience gives customers visibility of the leads they receive, and underpins how they review performance.

The problem

The legacy reporting experience was slow and unreliable with large lead datasets, and some views frequently timed out. It also needed a more robust foundation for future reporting and customer intelligence capabilities.

Constraints and complexity

  • Large lead datasets for some customers.
  • Behaviour that varied across different customer types and edge cases.
  • Customer data that needed careful handling in the browser.
  • A rollout that needed to happen in phases rather than as a single switch-over.

My role and ownership

What I owned

  • Frontend architecture and data flow
  • The permission model
  • Testing strategy across unit, integration and end-to-end layers
  • Phased rollout
  • Investigating legacy behaviour across customer types before defining the implementation

The wider team. Delivered within a wider product and engineering organisation, working with backend, product and design colleagues.

The approach

Before writing the new implementation, I investigated how the legacy reports behaved for different customer types and edge cases, so the rebuild could preserve what mattered and drop what didn't.

I then rebuilt the experience around a data flow that does the heavy work on the server and keeps the browser light.

Technical decisions

  1. 01

    Move data handling to the server

    Pagination, filtering, sorting and search happen server-side, so the browser only ever receives the page of results it is showing.

  2. 02

    React Query for the reporting data flow

    React Query manages fetching and caching, keeping loading and error states explicit and the components free of bespoke data plumbing.

  3. 03

    Charts that follow the timeframe

    Charts were rebuilt with Chart.js, and their granularity adapts to the selected timeframe across daily, weekly and monthly views.

  4. 04

    Privacy by data-flow design

    Data flows were redesigned so unnecessary personal information is not exposed in frontend payloads at all, rather than hidden in the UI.

Implementation

  • A React and TypeScript frontend working with Express, with reporting data flow driven by React Query.
  • Chart.js charts with granularity chosen from the active date range.
  • Jest and React Testing Library for unit and integration coverage, with Playwright for end-to-end flows.
  • React
  • TypeScript
  • Express
  • React Query
  • Chart.js
  • Jest
  • React Testing Library
  • Playwright

Outcome and impact

  • Replaced a legacy reporting experience that frequently timed out.
  • Improved reliability and performance for large datasets.
  • Established a foundation for future customer-facing reporting and intelligence features, including call transcription and AI-powered call intelligence.

Engineering principles

  • Understanding legacy edge cases up front is cheaper than rediscovering them in production.
  • Privacy is easiest to guarantee when sensitive fields never reach the client.

Next

Have a similar problem?

Give me a call to talk through the problem, scope and availability.