Vehicle Repair

Overview

This project improved the search and listing accuracy of a vehicle-service module. The module covers saved valuation records and nearby repair-shop discovery. It serves vehicle owners looking back at their valuation history and searching for a trustworthy repair shop close to them. It also serves the teams who need that data scoped to the right account.

Challenges

The 'view all valuations' experience didn't work properly. Filtering and pagination ran entirely in the browser with no server-side support behind them. Lists sometimes showed the wrong subset of records because visibility rules were not consistently enforced. That's a usability problem and a data-exposure risk at the same time. Year filters returned wrong results whenever values were compared as numbers in one place and as text in another. Ownership filters behaved unpredictably because empty, missing, null and zero values were all treated the same way. Loading was slow and sometimes incomplete because the full record list was pulled into the front end at once. The interface search, sort and filter state drifted out of step with what the backend actually returned. On the repair side nearby shop results looked inaccurate. Searches were anchored only to the centre of a postal code rather than a real address. Strict rating thresholds excluded legitimate shops. A fixed search radius left poor coverage in rural areas and too much noise in cities. Postal codes broke storage and validation because they were forced into numeric-only handling. And when map or search APIs failed users saw vague errors with no explanation.

Solution highlights

We moved filtering and pagination to the server where they belong. A new valuation listing endpoint accepts query-parameter filters for search text, make, year, ownership state and related metadata. It enforces account-level visibility so each list reflects exactly what the viewer is entitled to see. The front end now normalises filter values so numeric and text mismatches no longer break results. It requests pages from the API instead of loading the whole list into memory. For repair-shop discovery we made the search configurable. Both minimum rating and radius can be adjusted so urban and rural searches behave sensibly and legitimate shops are not filtered out too aggressively. Optional address-plus-postal-code geocoding positions the search far better than a postal-code centroid. Postal codes are now stored and validated as text including extended formats. We added optional keyword search to improve category matching. On-screen messaging tells users the active radius, rating threshold and any result limits so the results make sense. Validation and error handling around geocoding, places search and API failures were tightened with specific states for authentication, quota and no-result cases. We kept the valuation estimation model itself out of scope. The work stayed on the listing and search behaviour that was actually broken.

Key Features

• Server-side valuation listing endpoint with query-parameter filters
• Filters for search text, make, year, ownership state and related metadata
• Account-scoped valuation visibility enforced on each request
• Server-side pagination for large valuation histories
• Front-end filter normalisation for year, ownership, search and sort direction
• Nearby repair-shop search with configurable minimum rating
• Configurable search radius suited to both urban and rural contexts
• Address-plus-postal-code geocoding for accurate positioning
• Solid postal-code handling including text and extended formats
• Optional keyword search to improve repair-category matching
• Clear messaging showing active radius, rating threshold and result limits
• Improved validation and error handling for geocoding and places-search failures

Our Role & Approach

Our role here was surgical rather than sweeping. The client needed the broken listing and search behaviour fixed without a costly rebuild. So we set a tight scope up front and kept the valuation estimation engine outside it. We ran two parallel tracks. One was data correctness for valuations. The other was location accuracy for repair-shop search. Each closed with acceptance checks covering the correct result set, filter behaviour and location accuracy. We added targeted integration and regression tests around filtering, pagination and location search. These are exactly the areas where a small change quietly breaks something else. Where user confusion came from invisible rules we surfaced the rules in the interface rather than changing them silently.

Technology Stack

Backend: Django, Django REST Framework. Frontend: React, TypeScript. Integrations: Google Geocoding API, Google Places and Nearby Search API. AI: LLM-based valuation service. Data models: VehicleValuation, VehicleNearbyShopSearch. Security and configuration: account and tenant scoping, API key configuration, pagination limits.

Outcomes

Users can view, filter, sort and page through their full valuation history without the list stalling or breaking. Records stay scoped to the intended account so nobody sees the wrong data. Year and ownership filtering behaves consistently across all value types. Results match expectations. Large lists load quickly because the work happens on the server rather than in the browser. Repair-shop discovery returns noticeably more accurate location-aware results thanks to address-level geocoding and an adjustable radius. Adjustable rating thresholds keep legitimate shops in the results instead of quietly excluding them. The search radius and rating criteria are shown directly in the interface. Users understand why specific shops appear or don't. That removed a common source of complaints. External map and search failures produce clear actionable messages instead of silent confusion. Targeted test coverage makes future changes in these areas considerably safer to ship.