The challenge
An automotive spare parts business held a catalog of more than 5 million car parts. It needed auto parts catalog software that let users find one specific part in that list, quickly, on whatever device they had to hand.
A list that size defeats a spreadsheet. People also look for parts in different ways. Some know only their car's make and model. Others have a part number copied from an old box, or a few words that describe what they need.
Two more requirements shaped the build. Pages had to stay quick even when a query ran against millions of records. And the business wanted to learn which parts people searched for most, so it could see where its catalog was working hard.
What we built: auto parts catalog software for 5 million+ parts
We built a catalog portal with a React front end, a Node.js and Express API and a MongoDB database. We designed the back end and the database to hold and query the full catalog, not a trimmed sample of it.
Users can reach a part in four ways:
Browse with images across the whole catalog.
Pick a make and model to narrow the list to their car.
Type into a search bar that suggests matches as they go.
Search directly by exact part number or by words in the description.
Matches come back in a simple table showing part number, description, quantity and remarks. The layout works on phones as well as desktops.
Access is limited to designated users through role-based sign-in. Behind the scenes, the portal records page views and the search queries people type, which shows the business which sections and terms get used most.
How it works day to day
A designated user signs in to look up a part. They know the car but not the part number, so they choose the make and model and the list narrows to parts for that vehicle. A few typed letters bring up suggestions, and the right part appears in the results table with its quantity and remarks.
The next query might start from the other end: a part number read off a worn label. Advanced search takes it straight to the match. Users switch between browsing and searching depending on what they know about the part.
Every one of those searches is logged. Over time, the business sees which parts and terms draw the most attention, and that guides which areas of the catalog to keep current and where to add detail.
The result
Designated users can now find a specific part in a catalog of more than 5 million records from a phone or a desktop. They can start from a car, a part number, a description or an image.
The business, in turn, can see which parts and search terms get the most attention, instead of guessing which areas of its catalog matter.
What the research says
Most search tools fall short on parts queries. The UX research firm Baymard Institute found that 56% of sites fail to support users' search needs, and 44% struggle with compatibility searches, where users know the product they own but not the name of the part they need (Baymard Institute). A make and model selector answers exactly that kind of query.
Auto-suggest is common but often weak. Baymard also found that 80% of e-commerce sites offer search autocomplete, yet only 19% get all the implementation details right (Baymard Institute, autocomplete). In a catalog of millions of parts, good suggestions save users from guessing exact part names.
Most lookups happen on a phone. Statcounter, a web analytics company, put mobile at 77.3% of web traffic in India in September 2026, against 22.1% for desktop (Statcounter Global Stats). The portal's React front end adapts to phones as well as desktops.
Where AI fits next
The portal has no AI yet, but three ideas would fit it well. AI search could understand plain descriptions, such as "front brake pads for a 2015 hatchback", and map them to part numbers.
It could suggest equivalent or compatible parts when an exact match is out of stock. Logged searches that return nothing could be grouped to show gaps in the catalog.
Planning something similar?
Before you build a parts catalog or lookup portal, it helps to answer four questions:
How do your users identify a part: by vehicle, by part number, by description or by picture?
How many records must the catalog hold now, and in three years?
Who should see the catalog, and should it be open to buyers or limited to named users?
Which search data would change how you manage the catalog?
For the technical side, read our guide to choosing a tech stack for a web application. For the wider picture, look at how we take on large web applications and custom builds, and at our parts and retail projects.
