Hyvä for auto parts retailers: The complete guide
Auto parts ecommerce is one of the verticals where Hyvä migration pays back fastest. The combination of high-SKU catalogues, vehicle compatibility lookup, trade-account pricing, and mobile-heavy traffic (mechanics buying parts on their phones from the workshop) creates a perfect storm of Luma performance pain.
We've shipped Hyvä for several auto parts retailers in the UK — from independent specialists to larger aftermarket aggregators. This post is the auto-parts-specific guide: what's different about the vertical, which Hyvä features matter most, and the pattern we use.
Why auto parts is different
Five vertical-specific demands that affect Hyvä implementation:
1. Massive SKU catalogues (50k–500k+ products)
Auto parts catalogues are SKU-heavy. A typical aftermarket aggregator covers parts for 50+ vehicle makes × 20+ models per make × 10+ years per model × 50+ part categories. That's potentially hundreds of thousands of SKUs.
Hyvä handles this fine — the storefront performance question is separate from catalogue size — but the search + navigation surfaces need careful design. Default Magento PLP rendering for a 500k-product category isn't usable; you need faceted search, vehicle-narrowed filtering, and meaningful merchandising.
2. Vehicle compatibility lookup (year / make / model / engine)
The core "find your part" UX in auto parts is a year-make-model-engine cascading dropdown. Customer enters their vehicle; results filter to parts compatible with that vehicle.
This is a complex frontend interaction with real-time backend lookup. Hyvä's Alpine.js approach handles it cleanly — the cascading dropdowns are a natural Alpine component, the API call to filter results is straightforward, and the URL state preservation (so a customer can bookmark "parts for my 2018 Ford Focus 1.5") is standard Hyvä routing.
3. Trade-account pricing tiers
Auto parts retailers commonly have multiple pricing tiers — retail price, trade discount tier 1, trade discount tier 2, fleet pricing. The PDP and PLP need to render the right price per logged-in customer.
This is bread-and-butter B2B Magento (or Adobe Commerce B2B) functionality, and Hyvä re-templates it cleanly. The PDP shows the customer's tier price; the cart applies their tier discount; the checkout shows their VAT registration handling.
4. Multi-warehouse stock + delivery
Stock comes from multiple warehouses — often a UK central warehouse, regional sub-warehouses, and supplier drop-ship arrangements. The PDP needs to show "in stock here, available for next-day delivery" or "available from supplier in 3–5 days" depending on which warehouse the part lives in.
Hyvä handles this via standard Magento inventory backend + Hyvä template per-warehouse rendering. The UX work is in displaying the stock + delivery information clearly without overwhelming the customer.
5. Mobile-heavy professional traffic
Auto parts has high mobile share — mechanics in workshops, fleet managers in vans, DIY enthusiasts in garages. Mobile Lighthouse performance directly affects conversion because slow PDP rendering = customer goes to the next supplier.
This is where Hyvä's biggest win lives. Auto parts merchants on Luma typically see mobile Lighthouse in the 30s–50s. The same stores on Hyvä typically see 85–92.
What Hyvä changes for auto parts specifically
The Hyvä Theme + Hyvä Commerce features that matter most for auto parts:
Hyvä Theme for high-SKU catalogue performance
Default Luma PLP performance degrades badly above 1,000 products in a category. Hyvä's lighter render pattern + Alpine-based facet filtering handles 10k+ product PLPs cleanly.
For very large categories (50k+ products), the combination of Hyvä Theme + a proper search index (Elasticsearch / OpenSearch) + faceted navigation gives a usable browse experience even on entry-level mobile devices.
Hyvä Checkout for high-conversion checkout
Auto parts has a specific checkout pattern: customers know exactly what they want (they've already looked up the part for their vehicle), add to cart, and want to checkout fast. Multi-step Magento default checkout adds friction; Hyvä Checkout's one-page flow matches the buyer's mental model.
Conversion lift on Hyvä Checkout for auto parts merchants in our portfolio: +12–18% mobile checkout completion (slightly higher than the cross-vertical average because the trade-account buyer is impatient).
Hyvä for Adobe Commerce B2B features
Larger auto parts merchants on Adobe Commerce use B2B features for:
- Trade-account onboarding (application → approval → account activation)
- Company-level pricing tiers
- Customer-specific catalogue visibility (e.g. fleet customers see commercial-grade parts)
- Requisition lists ("save this parts list for monthly reorder")
- Approval workflows for orders above £X
Hyvä re-templates each of these surfaces. The implementation is standard Adobe Commerce B2B + Hyvä; the vertical-specific work is in the UX (making sure the trade-account experience feels like a workshop tool, not a B2C storefront).
Vehicle compatibility lookup — the implementation
The year-make-model-engine lookup is the single most-asked-about Hyvä feature for auto parts. The pattern we use:
Data model
- A separate
vehicle_compatibilitytable (or similar) mapping product SKU → compatible vehicle (year + make + model + engine) - Lookup data sourced from your existing parts catalogue (TecDoc, ETKA, your own data, or aggregator feeds)
Frontend implementation
- Alpine.js cascading dropdown component: select year → loads makes → select make → loads models → select model → loads engines
- Each step makes a small API call to load options for the next step
- "Find parts" button submits the vehicle selection as URL parameters:
?year=2018&make=ford&model=focus&engine=1.5 - PLP renders only products compatible with that vehicle
- Vehicle selection persists in cookies / localStorage so customer doesn't re-enter it on every page
Search integration
- Site search respects vehicle filter — typing "brake pads" with a vehicle selected returns only brake pads compatible with that vehicle
- Empty search results offer "search across all vehicles" escape hatch
Garage / saved vehicles
- Logged-in customers can save multiple vehicles in their account
- "My garage" UI to switch between saved vehicles
- Sticky vehicle selector in the header showing current selected vehicle
Total implementation effort: 2–3 weeks beyond standard Hyvä Theme build. Reusable component once built — most auto parts merchants on Hyvä use a variation of this pattern.
Trade-account pricing on PDP
The PDP needs to show different prices to different customer tiers. Standard pattern:
- Guest customer: retail price
- Logged-in trade tier 1: "Trade price: £X (you save 15%)"
- Logged-in trade tier 2: "Trade price: £X (you save 25%)"
- Logged-in fleet customer: custom contract price + "Your fleet rate"
Implementation: standard Magento customer-group pricing + Hyvä template conditional rendering. The Hyvä work is the UI design — making the trade tier feel like a benefit, not just a discount.
Multi-warehouse stock display
For multi-warehouse merchants, the PDP shows:
- Primary warehouse stock + delivery estimate ("In stock, next-day delivery if ordered by 4pm")
- Secondary warehouse availability ("Also available from regional warehouse, 2-day delivery")
- Supplier drop-ship option ("Available from supplier, 3-5 day delivery")
Hyvä's template flexibility makes this clean — typically a stock-availability component that pulls from Magento's inventory backend and renders per-warehouse states. The customer sees clear delivery promises rather than ambiguous "in stock."
The Hyvä auto parts implementation typical scope
For a mid-size auto parts retailer:
- Magento Open Source or Adobe Commerce (with or without B2B)
- 50k–200k SKUs
- Vehicle compatibility lookup
- Trade-account pricing (2–4 tiers)
- Multi-warehouse stock
- 10–20 paid extensions
- Custom Hyvä compat for niche aftermarket-specific extensions
Timeline: 10–14 weeks Cost: £45k–£75k (Magento Open Source) or £60k–£100k (Adobe Commerce with B2B features) Mobile Lighthouse lift: typical +35–45 points (auto parts has high baseline Luma drag) Mobile checkout completion lift: +12–18%
Case study: aftermarket aggregator
Recent project: UK-based aftermarket parts aggregator, 180k SKUs, vehicle compatibility for 60+ vehicle makes, Magento Open Source, 15 paid extensions.
Before: Mobile Lighthouse 38, mobile checkout completion 41%, PLP load time 6.5s on 4G.
Hyvä Theme + Hyvä Checkout migration, 11 weeks, £62k.
After: Mobile Lighthouse 87, mobile checkout completion 53%, PLP load time 1.9s on 4G.
Conversion lift: +29% in mobile orders within 60 days of cutover. Migration paid back in 4 months.
(Numbers approximate; we publish full case studies under NDA on request.)
Auto parts merchants we wouldn't migrate
Three scenarios where we'd push back:
1. Pre-revenue or very small (<£250k annual revenue). Migration cost vs conversion lift doesn't pencil out. Focus on getting traffic + first revenue first.
2. Planning a platform switch to a vertical-specific solution. If Brightpearl Auto, Catalogo, or another aftermarket-specific platform is on the 12-month roadmap, don't sink £60k into Hyvä first.
3. Custom in-house frontend without ecommerce engine. Some auto parts merchants run on bespoke PHP + custom databases. Migrating to Hyvä means first migrating to Magento, which is a much bigger project.
For everyone else doing meaningful aftermarket revenue on Magento, Hyvä is almost always the right call.
Next steps
- See the Hyvä Migration service page for the general migration process
- Read Hyvä for high-SKU catalogs for catalogue-size-specific guidance
- Read Hyvä for B2B Ecommerce for trade-account specifics
- Book a scoping call for an auto-parts-specific fixed-price quote