Apex
A dealer plugin designed to offer only accessories that fit the listed vehicle
Apex set out to show dealer shoppers the accessories that fit the car, motorbike or side by side they are viewing. We kept data collection apart from matching, built per site crawlers into one fitment catalog and designed the plugin as one button on dealer pages.
Automotive & DealershipsDealer accessory matching pluginBuilt from zero
The challenge
Fitment sat on many maker and retailer sites, each structured differently and written in free text, while dealer listing titles rarely matched it exactly.
What we did
Per site crawlers into one normalized fitment catalog, text matching kept to the same maker, and a plugin designed as one button and an iframe on dealer pages.
The outcome
The client received the architecture, schema, screen designs and working crawlers with shared data. The product did not launch, and he rated the work five stars.
- What we built
- Per site crawlers and one fitment catalog
- What we designed
- Plugin architecture, shopper and dealer screens
- Matching
- Text similarity, same maker only, no generative model
- Status
- Groundwork delivered, product not launched
The starting point
Project APEX was a new accessory product for dealers that list cars, motorbikes and side by side vehicles on their websites. Shoppers had no easy way to add fitting accessories, such as headlights or bumpers, at the moment of interest.
What had to change
Accessory data lives on many manufacturer and retailer sites, each structured differently, and fitment is written in free text that lists models, variants and model years. Dealer listing titles rarely match that text exactly, so a plain lookup fails.
What could not break
- Accessories come only from the same maker as the vehicle
- Dealer sites stay untouched apart from one button
- Fitment text arrives in a different shape on every source site
- The catalog is built to refresh daily as supplier data changes
The calls we made
We separated collecting accessory data from matching it, so each could be fixed and improved on its own.
- 01
One output shape for every site
Each site got its own crawler, but every crawler returned the same fields into one database of products, categories, models by maker and compatibility, so matching never depends on how a single site is built.
- 02
Rules and text similarity, filtered by maker
Fitment is a match between a listing title and compatibility text, kept to the same maker, so a Honda bike only sees Honda accessories. Rules and text similarity keep every match checkable by a person.
Ruled outA plain lookup on listing titles, which fails when the wording differs.
- 03
One button on the dealer page
The button sends the vehicle title to our endpoint and opens an iframe, so matching, data and leads live behind the endpoint and dealer sites stay untouched apart from that button.
Ruled outChanges inside each dealer's own site code.
How the system fits together
What we built
Plugin and dealer screens
The architecture for the listing page button, the matching endpoint and the accessory iframe, plus designs for the shopper's picker and a dealer portal that lists each accessory lead with the vehicle and the chosen items.
Per site accessory crawlers
Scrapy crawlers for the accessory sites the client chose, each returning title, price, style number, category, availability, compatibility text and category path in one JSON shape.
One fitment catalog
A MySQL schema for products, category variants under parent categories such as bumpers and guards or fender flares, model names by maker and product to model compatibility.
How it works
Collect
Per site crawlers, designed to run daily, pull accessories and their compatibility text into the catalog.
Click
A shopper on a vehicle listing taps the add accessory button.
Match
The endpoint compares the vehicle title with compatibility text and keeps only the same maker's accessories.
Capture
The shopper adds or removes accessories in the iframe and submits a lead for the dealer's portal or email.
A closer look
What changed
The client received the plugin architecture, the fitment schema, the screen designs and working crawlers with shared accessory data. The product was not launched, and the client still rated the work five stars and recommended the team.
Under the hood
- Datics role
- Product built by Datics
- Integration
- A button and an iframe on dealer listing pages, calling a backend endpoint with the vehicle title.
- Data
- Accessory data crawled from the client's chosen sites into one MySQL schema, built for a daily refresh.
- Boundary
- Matching uses rules and text similarity on crawled compatibility text, with no generative model.
Apps and APIs
Also in the stack
How it shipped
Architecture and schema
A high level architecture and a database schema for products, categories, models by maker and compatibility.
Crawlers in rounds
A crawler plan per site, with each crawler delivered and its scraped data shared with the client as it was ready.
Plugin and screen designs
The listing page button, the matching endpoint and the iframe, with designs for the shopper's picker and the dealer lead portal.
A crawler plan per site
We planned the crawlers site by site, delivered them in rounds and shared the scraped accessory data with the client as each one was ready.
The whole feature on paper first
The architecture, the database schema and the screen designs were set out before the build, so the client could review the full shopper and dealer journey.
What this unlocked
The same pattern, one normalized catalog and a single button on existing pages, is how a dealer platform can add accessory offers without rebuilding its sites.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.