
Year, make and model search that only shows parts that fit
Automotive Ecommerce
An auto parts store built around fitment: year, make and model search that only shows parts that fit, ACES and PIES data kept current, and a catalog that stays fast at any size.
Plan Your Parts StoreFitment before design
ACES fitmentPIES product data
A parts store does not sell a product to anyone who likes it. It sells one part to one vehicle, and a brake pad that fits the 2019 model and not the 2020 one is a return, a refund and a customer who orders from someone else next time. Every page, search box and filter on the store exists to answer one question correctly: does this fit my car?
The answer lives in the data. The aftermarket describes it in two standards from the Auto Care Association: ACES for fitment, which vehicles a part is designed to fit, and PIES for product information, the attributes, dimensions and content. Both are XML files built on reference databases such as the Vehicle Configuration database, which covers light, medium and heavy duty vehicles, powersports and off-highway equipment.
So the build starts with the catalog rather than the theme. We have built ecommerce since 2006 and Magento since 2008, and a parts store is the clearest case we know for getting the data model right before anyone draws a page.
Does this sound familiar?
Each one ends the same way: a customer who is not sure the part fits, and buys it somewhere that told them it does.

The listing said it fits, the vehicle disagreed, and the part comes back with a refund, two shipping labels and a review nobody wanted.

A shopper types a part name and gets every brake pad in the catalog. Without a vehicle in the search, the store hands the fitment question back to the customer.

Suppliers send new ACES and PIES files every month. A store that loads them by hand twice a year is selling against last season's applications.

Hundreds of thousands of SKUs and millions of fitment rows, on a platform and a search index sized for a few thousand products. Category pages crawl.

Repair shops and fleet buyers want their own prices, quick order by part number and an account. The retail store gives them a shopping cart and nothing else.

Core charges, oversized freight and hazardous shipping rules do not fit a checkout built for t-shirts, so they are added by hand after the order or not at all.
What the build includes

A vehicle selector that remembers the car, filters every listing and search result to parts that fit, and says plainly when a part does not.

Supplier fitment and product files loaded, mapped to the store's own attributes and refreshed on a schedule, with the rejects reported rather than skipped.

Search by part number, OE number or a competitor's number, with interchange data linking each one to the parts the store actually stocks.

The search index, category pages and fitment lookups built and measured for hundreds of thousands of SKUs, so the store is fast on a phone in a parking lot.

Core charges added and refunded, oversized parts quoted for freight, and hazardous items shipped only by the methods allowed to carry them.

Listings on marketplaces such as Amazon and eBay fed from the same catalog, and an account area where shops and fleets order at their own prices.
How a parts store is built
What you are left with
2,048 variants per Shopify product
A store where a shopper picks a vehicle once and sees only what fits, in search, categories, the product page and the cart, and is told before the order when a part does not fit.
Behind it, a data pipeline you can trust: supplier files load on a schedule, rejected rows are reported with a reason, and part, OE and interchange numbers lead to the right SKU. Checkout knows cores, freight and hazmat, and shops have accounts.
And a platform chosen for the catalog. Magento carries large catalogs and custom fitment well; a Shopify product holds at most 2,048 variants, so fitment there lives in its own data.
Where to begin
The full build: the catalog and fitment data model, the vehicle selector and search, the import for supplier files, checkout rules for cores and freight, and the integrations behind it, on the platform your catalog calls for.
Repair shops, dealers and fleet buyers ordering on account: their own prices and catalogs, quick order by part number, reorder from history, purchase orders and terms, beside the retail store on the same catalog.
An AI assistant on the store that asks for the vehicle once, answers in plain language and only recommends parts that fit, with add to cart and order tracking inside the conversation.
Platforms we build on
Trusted by 100+ companies
Keep reading



FAQ
Tell us about your store and we will come back with straight answers.
Talk to usBuilding an online store whose job is to sell the right part for a specific vehicle. That means a catalog and data model built around fitment, a year, make and model search, an import for supplier ACES and PIES files, search by part and OE number, checkout rules for cores and freight, and often a B2B area for shops and fleets. The storefront design matters, but the data decides whether customers trust it.
They are the aftermarket's data standards, maintained by the Auto Care Association. ACES carries fitment data: which vehicles a part is designed to fit. PIES carries product information: attributes, dimensions, packaging and content. Both are XML files built on reference databases such as the Vehicle Configuration database, and suppliers send them to the sellers who list their parts.
Yes. We build an import that reads the files, maps them to the store's own attributes and vehicle data, and runs on a schedule so new applications arrive without anyone loading them by hand. Every row it cannot use is reported with a reason, so bad supplier data is fixed at the source instead of quietly disappearing.
The shopper picks a vehicle once, the store remembers it, and every search result, category and product page is filtered to parts that fit. Where a part does not fit the chosen vehicle, the product page says so plainly. The selector can go further than year, make and model, to engine and submodel, where your fitment data carries them.
It depends on the catalog. Magento handles very large catalogs and custom fitment tables well. Shopify suits a focused range, with fitment held in its own data, because a Shopify product holds at most 2,048 variants and fitment cannot be modelled as variants. BigCommerce sits between them. We recommend after we have seen your catalog and your supplier data, not before.
Yes, for the right catalog. Fitment on Shopify lives in its own data and is served through an app or a custom build, rather than as product variants, which are capped at 2,048 per product. For a focused range with good supplier data that works well. For hundreds of thousands of SKUs with deep fitment, Magento is usually the stronger home, and we will say so.
By catching the mismatch before the order. The vehicle is stated once and carried through the whole store, the product page confirms fit or says plainly that a part does not fit, and the cart checks again. After launch we watch the return reasons, because a cluster of returns on one part is usually a data problem with a fix.
Yes. Search takes your part numbers, original equipment numbers and, where you have interchange data, other manufacturers' numbers, and leads each one to the part you stock. Mechanics and parts professionals search that way first, so it is built in rather than added later.
As checkout rules. A core charge is added to the order and refunded when the old part comes back, oversized parts are quoted for freight instead of parcel rates, and hazardous items are offered only the shipping methods allowed to carry them. Which carriers and rules apply depends on what you sell and where you ship, so we set them with your shipping team.
Yes. Shops, dealers and fleet buyers get accounts with their own prices and catalogs, quick order by part number, reorder from history, purchase orders and terms, beside the retail store on the same catalog. Our page on B2B for distributors covers that side in more depth.
Yes. Orders, stock and prices move between the store and your ERP, and marketplace listings such as Amazon and eBay are fed from the same catalog and fitment data, so one correction fixes every channel. The integration list is written in the first step, before anything is built.
It depends mostly on the data. A focused catalog with clean supplier files can launch in a few months; a large catalog with several suppliers, B2B accounts and an ERP takes longer, because the import and the fitment data model are most of the work. The plan from the first step gives you the dates for your store.
Individually, once we have seen the catalog, the supplier data, the platform and the integrations. Fitment and data work vary more than design does, so a number given before that read would be a guess. Send us the basics and you have a scoped plan within two business days.
Yes. We start by reading the store and its data: how fitment is stored, how supplier files arrive, what the import rejects and where the wrong-part returns come from. Our project rescue service covers the takeover itself, and the fitment work follows the same plan as a new build.
Let’s build something great together!
Send us your platform, a sample of your supplier files and how many SKUs you carry. Within two business days we come back with how we would model the fitment and what the build would take.