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.
Loading interactive demo… Change the date range, switch the chart view, hover the bars, search and filter the table.
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
- 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.
- 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.
- 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.
- 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.