Background
OldMoParts sells restoration parts for classic Mopar vehicles. The catalog had grown over several years on a WordPress site running WooCommerce, and the site had become an obstacle to the business rather than a channel for it. I designed and built the replacement.
The problem
The site was slow in ways that cost sales. Category pages took seconds to render, search lagged, and checkout felt unreliable. Inventory was difficult to manage, so the catalog drifted out of sync with what was actually in stock.
The more important problem was specific to the domain. A customer shopping for a 1969 Charger wants to see the parts that fit that car, not the full catalog. Fitment, meaning whether a part fits a given year, model, and engine, was handled poorly. Customers bought parts that did not fit, or left the site to call and ask.
Constraints
The retailer is a small business with a large catalog and one person managing it. The administrative experience mattered as much as the storefront.
Years of inbound links and search rankings pointed at the old URLs. Breaking them would have cost more than the redesign gained.
The fitment data was inconsistent, and maintaining it would remain the retailer’s responsibility after launch.
Approach
Moving to Shopify was settled before any design work started. The retailer was managing inventory in one system and selling online through another, and Shopify would put both in one place.
The open question was what the customer-facing site would be: a Shopify theme, or a separate storefront built on Shopify’s API. A theme would have been faster to launch but we chose the separate storefront because it gave us custom urls for marketing, more flexibilty in the design and greater control over the fitment experience, which the client wanted to extend beyond filtering. One example was showing a photo of the customer’s selected car in the page header. No theme or fitment app we evaluated supported that, and the apps carried a monthly fee on top of it.
I built the storefront in Next.js rather than Nuxt, which is what I use for most client work. Shopify’s headless ecosystem is React-first, Algolia ships Next.js-specific packages for its search UI and routing, and Vercel’s hosting is built around Next.js. It was also a deliberate choice to do a full project in React.
What I built
The fitment model is designed to be maintained by the retailer. Vehicles, years, and engines live in a single structured data file. Products carry tags that resolve against it. When a customer selects a vehicle, the storefront compares it to every product and displays one of a few states: guaranteed fit, fits but requires an engine selection, or does not fit. The selection persists across the session, so the entire catalog filters itself as the customer browses.
Search and filtering run through Algolia. The catalog is indexed from Shopify with fitment attributes exposed as facets, so search is immediate and filtering by vehicle is part of the normal search experience rather than a separate flow.
The storefront is built on the Next.js App Router with a static-first approach. Product and category pages are rendered ahead of time, and checkout is handed to Shopify at the final step.
Every legacy URL redirects to its new location. Redirects are processed at the edge before a request reaches the application, so the previous site’s search equity carried over.
Vehicle and make landing pages are generated from the fitment data, giving search engines a page per vehicle without anyone writing them by hand.
Results
Monthly sales after launch were substantially higher than before.
On the engineering side, the storefront loads in a fraction of the previous site’s time, search results appear as the customer types, and the retailer manages inventory through Shopify’s admin rather than a WordPress plugin.
Looking back
I would capture baseline performance and sales numbers before beginning. I know the old site was slow and that sales increased, and I would prefer to state both precisely. I would also build the fitment data validator at the start of the project rather than the end. Cleaning the data was the longest single task, and a validator on day one would have made that visible early.