SYSTEM Integration
  • Agency · white label
  • Magento 2
  • Manufacturer
  • Auto parts
  • B2B + B2C
  • Parts finder

Engine Parts E-commerce Built from Scratch

Nearly 7,000 online orders, about 200,000 part lookups by vehicle or engine, and continuous development after launch without stopping sales.

Search bar suggestions with make, model, year and engine combinations

Project

Delivered for
Digital agency, white label
Client
International manufacturer of precision engine parts
Platform
Magento 2 Open Source 2.4.7 (replaced a custom PHP 5.6 store)
Catalog
~29,000 products, two websites in one installation
Timeline
7 months
Team
2 back-end, 1 front-end, 1 QA

About the Client

The client is an international manufacturer of precision engine parts with more than half a century of history. It makes components for passenger cars, light and heavy trucks, marine engines, generator sets and other types of internal combustion engines, and runs a separate performance line for racing and tuned engines that is tested in the lab and on the track.

Manufacturing is fully in-house, from materials to finishing, packaging and warehousing, and the company has its own R&D lab. Its parts go into series production engines and race engines around the world. It sells through a network of official distributors, dealers and wholesale partners, through large marketplaces, and directly to end customers online.

Before the project, the company sold online through a custom-built store on PHP 5.6, a version that stopped receiving security updates back in 2018. The design was dated and inconvenient for buyers, and every change to the old code was slow and risky. The client needed a new online store built from scratch: one that would let both retail buyers and professional engine builders find exactly the right part, support the dealer network, and protect the brand.

The company in numbers

  • About 14,000 products for different engines and platforms.
  • Official distributors worldwide.
  • An online store with a catalog of about 29,000 items, plus a separate catalog website without prices.
  • More than 20 proprietary technologies in materials, coatings and part geometry.

Main Challenges the Customer Faced

Business challenges

  1. Business challenge 1

    Precise part selection in a complex technical catalog

    The catalog has about 29,000 items, and many parts differ from each other by hundredths of a millimeter. For the buyer, a wrong size means an engine that is already taken apart and a wait for the replacement. For the store, it means a return, extra logistics and a lost customer.

    The client needed both a retail buyer and a professional engine builder to find their part quickly and with confidence: by vehicle, by engine, by dimensions, or straight from the search bar.

  2. Business challenge 2

    Higher average order value and repeat purchases

    A buyer rarely needs just one part. A repair takes a set, and customers come back to the same vehicle again and again. The client wanted to suggest related parts at the moment of purchase, make every repeat visit as short as possible, and learn which vehicles people buy for most often.

  3. Business challenge 3

    Brand protection against counterfeits

    Premium parts get counterfeited, and fakes damage the brand: a low-quality copy fails, and the complaint goes to the original manufacturer. On top of that, the company didn't know the end owners of parts bought through dealers and marketplaces. It needed a simple way for buyers to check that a part is genuine and register it in their name.

  4. Business challenge 4

    Scaling the dealer network without more manual work

    The company sells through its own store, dealers, wholesale partners and large marketplaces, and the number of channels keeps growing. Every partner needs its own prices and terms, while accounting and marketing need accurate data across all channels. The goal was to onboard new partners and launch new segments without development work, and to automate the routine of exports and reconciliations.

Technical challenges

  1. Technical challenge 1

    Extending an ecosystem of ready-made modules without forking

    The store runs on Magento with almost a hundred third-party extensions: parts finder, search, cart, preorders, company accounts. Almost every change we made altered the behavior of one of those modules. Copying and rewriting someone else's code was not an option: a store like that stops receiving updates and accumulates vulnerabilities.

    We built every change through the platform's extension points. The store survives updates of third-party modules, and if an update does affect a customization, it is restored in one place, without rewriting.

  2. Technical challenge 2

    Large data volumes and fast search

    Behind the catalog are about 2 million compatibility links of the form "vehicle or engine to part", and technical dimensions were stored on products as plain text. That data had to become fast search: suggestions in the search bar across more than 220,000 vehicle and engine combinations, numeric search by dimensions with a tolerance, and compatibility tables on the product page, without slowing the site down. We built our own search indexes and our own queries to the search engine for this.

  3. Technical challenge 3

    Product variants, warehouses and two websites in one system

    One part is sold in several repair sizes and versions, each variant has its own stock, and some variants are available only for preorder. At the same time, one installation runs two websites: the online store and a catalog without prices, each with its own warehouse, its own finder profiles and its own display rules.

    Standard Magento logic is designed for simpler cases, so variant selection, stock, preorders and back-in-stock alerts had to be reworked down to the level of a single size and a single website.

Delivery challenges

  1. Delivery challenge 1

    Launching from scratch in small releases

    The new store replaced the old custom one and had to be built from nothing: a catalog of tens of thousands of items, compatibility data, checkout with online payment, integrations, and two websites in one system. From day one we separated development, testing and production environments and shipped changes through a dedicated testing branch. The launch happened as a series of small releases, not one risky switch-over.

  2. Delivery challenge 2

    Continuous development without stopping sales

    After launch the project moved into continuous development, and the store kept selling the whole time. The team shipped several hundred changes through pull requests with code review and regularly installed platform security updates.

    The team composition changed during the project. To keep quality independent of who is on the team, every task lives in its own branch and goes through review, and complex customizations come with handover documents, so a new developer gets up to speed quickly.

What we did

Solution 1

My Garage and a demand report

Part selection in the store is built on a ready-made parts finder module: the buyer picks make, model, year and engine and gets a list of matching parts. We built My Garage into it, so buyers don't have to go through four dropdowns on every visit, and so the store learns which vehicles people are shopping for.

For the buyer

  • A registered buyer's vehicle is saved to the garage automatically as soon as they run a search in the finder. No separate "save" button is needed.
  • A garage icon with a counter sits in the site header. Its dropdown lists saved vehicles, and one click takes the buyer back to the parts selected for that vehicle.
  • The customer account has a My Garage page: vehicles are shown as tiles with images, extra ones can be removed, and a new one can be added through a window with the finder fields.
  • Guests can use the garage too. Their vehicles are kept in the browser and move to the account automatically after login or registration.

For the store team

  • The Top My Garage report in the admin shows the most popular make, model, year and engine combinations and how many customers have each one saved. It can be filtered by period and by finder.
  • The same report can be opened to selected customer groups in the Reports tab of their account.
  • The garage is switched on and configured per finder: name, guest access, default image, report settings.

How it works

  • The garage stores the original finder selection, not a copy of the vehicle data. Labels, images and result links are built by the finder module every time, so a garage link leads to the same page as a fresh search, and renamed entries in the reference data are picked up automatically.
  • Saving is built into the finder form without changing the third-party module's code. If saving fails for any reason, the search still runs.
  • Garage data loads separately from the page, so the catalog is still served from the full-page cache and the site keeps its speed.

Solution 2

Related parts recommendations

Recommendations appear in the two places where the buyer has already decided to buy: in a popup right after adding a product to the cart, and on the cart page. Both suggest parts that are usually needed together with the chosen one, most often components for the same engine that are installed in the same repair.

For the buyer

  • After clicking Add to Cart, the product is added without a page reload. A window opens with a confirmation, buttons to the cart and checkout, and a carousel of recommendations.
  • Each recommendation card has a photo, name, price and an Add to Cart button. If the part comes in several variants, the variant is chosen right in the card, without opening the product page.
  • On the cart page, recommendations are collected for all products in the cart at once, without duplicates.
  • Only products that can be bought right now are recommended, including those available for preorder.

For the store team

  • The manager decides what to suggest together, in the product card, through standard Up-Sell links, without developers.
  • Block titles and the number of products in the popup and in the cart are set in the admin.

How it works

  • The add-to-cart popup is a third-party module. It had no up-sell option, so we added one as a new block type without changing the module's code.
  • The cart receives a specific variant, for example the right size, while recommendation links are set on the parent product. We keep the link between the variant and its parent at the moment it is added, so recommendations are correct and links in the popup lead to the visible product page, not to a hidden variant.
  • The recommendation limit is applied after unavailable products are filtered out, so sold-out items don't reduce the number of recommendations shown.
  • For preorder products, the button label in each card updates separately when the buyer picks a variant.

Solution 3

Product authenticity check and warranty registration

Every part comes in packaging with a sticker carrying an individual code. We built an authenticity and warranty page on the site: with this code, the buyer checks that the part is genuine and activates the warranty. Codes reach the site from the manufacturer's system through an API we built for this.

For the buyer

  • A code can be checked without logging in. The system answers in one of three ways: code not found, code already registered, or genuine part. In the last case it shows the part's photo and name, so the buyer can compare them with what they are holding.
  • If a code has been checked before but not registered, the buyer sees a warning.
  • Registration asks for the date, place and country of purchase; the price is optional. If the buyer isn't logged in, a login window opens and the entered data is kept: after login or sign-up, the registration completes automatically.
  • Registered parts are listed in a separate section of the customer account: code, SKU, purchase date and registration date.

For the store team

  • The admin has three sections: the code database with activation status, all registrations with CSV and XML export, and a log of every code check with the system's answer, SKU, email and IP.
  • A registration is linked to an order automatically if the buyer bought that part in the store. A part bought elsewhere can be registered too.
  • Through the API, external systems receive registrations and the check log, and upload or update codes in bulk.

How it works

  • Bulk code upload has two modes: add new codes and skip duplicates, or update existing ones. Sending the same batch again doesn't create duplicates.
  • Marking a code as used and creating the registration happen in one database transaction. That enforces the rule: one code, one registration.
  • To link a registration to an order, the system looks for the latest order with the same SKU and buyer email that isn't already linked to another registration.

Solution 4

Catalog table view for comparing parts by specification

We implemented and extended our own extension for this catalog: a table view for categories. Parts for the same engine often look almost identical, and whether they fit depends on dimensions and specifications. In a table, the buyer compares parts by specification on one page instead of opening product pages one by one.

For the buyer

  • In categories with table view, each part is a row, with specifications and price in columns. Clicking a column header sorts the list ascending or descending.
  • Results of a vehicle search (make, model, year, engine) open as a table right away.
  • A row expands without a page reload, showing a specification table in millimeters and inches, specific to the part type, plus photo, price, stock, variant selection and an Add to Cart button.
  • At the bottom of the page the buyer chooses how many parts to show: 100, 200 or 300.
  • A category can be shown split into subcategories, each with its own table.
  • On a phone, table rows turn into cards with a label for every value.
  • On the client's second website, the catalog without prices, the table works the same way, without the price and the buy button.

For the store team

  • Table view is switched on per category, and child categories can inherit the parent's settings.
  • The set of columns is configured in the admin, globally or per category. Specifications used as filters are added to the table automatically when products on the page have values for them.

How it works

  • The table is built into Magento's standard product list through plugins, without separate pages or controllers, so filters and pagination work exactly as in the normal view.
  • A category's settings and those of all its parents are loaded in one database query, and the settings of the nearest category that has them are applied.
  • Column values are added to the main product list query, so the table doesn't run a separate database query for each row.
  • The split into subcategories respects the filters the buyer has selected.

Solution 5

Finding the right part three ways

Buyers start with different information: one knows the make, model and year, another only the engine code, a third has nothing but the measurements of the old part. We made sure the right part can be found any of these ways, and that the product page shows at a glance what the part fits.

For the buyer

  • Search by vehicle or by engine: a chain of dropdowns where each list fills after the previous choice. Results open as a table headed with the selected vehicle or engine.
  • Search straight from the search bar: start typing a make and model, and the suggestions show a separate block of ready-made make, model, year and engine combinations. A click opens the same results as the manual finder, and the chosen values are filled into the finder form.
  • Search by dimensions: if the engine is non-standard, the buyer finds the part by its measurements (see Solution 9).
  • The product page has compatibility tabs: which vehicles and engines the part fits, and which parts it is interchangeable with. Rows that differ only by model year are merged into ranges like "2005–2010", and long lists show the first 10 rows with a button to expand.

For the store team

  • Compatibility data is managed in the finder module, with separate finder profiles for each of the client's two websites.
  • The search-bar suggestion block is switched on in the settings, with its title, number of rows and the profiles hidden on a given website. Each finder dropdown has a flag for whether it takes part in suggestions.
  • An admin report shows which vehicles and engines are searched most often.
  • Search by dimensions needs no setup: it works from specifications already filled in on products.

How it works

  • The ready-made finder module shows one compatibility table on the product page. We built a shared mechanism for several tabs with different profiles: data arrives in a separate request after the page loads, empty tabs are hidden, and years are collapsed into ranges.
  • For search-bar suggestions, the make, model, year and engine tree is flattened into a search index of every complete combination, built by a dedicated indexer. A click on a suggestion uses the standard finder handler, so results match a manual selection exactly.
  • Search by dimensions runs on our own numeric index of specifications, described in Solution 9.
  • Vehicle search results open in the table view from Solution 4.

Solution 6

Size selection with stock status for every variant

The same part is sold in several sizes, and some products have variants defined by two options. Each variant is stocked separately and can sell out before the others. We reworked variant selection on the product page so the buyer immediately sees which sizes are in stock and, if the right one isn't, can subscribe to a restock alert or place a preorder.

For the buyer

  • Size buttons carry a colored status: in stock, low stock (1 to 10 units), sold out, or available for preorder.
  • For products with two options, choosing the first leaves only existing combinations in the second. The order of selection doesn't matter: it recalculates both ways.
  • When the variant is fully selected, its stock is shown, with the exact number of units left when stock is low.
  • A sold-out size can still be selected. If preorder is enabled for it, the buy button stays active and a preorder is placed. If not, a registered buyer subscribes to a restock alert for that exact size and gets an email with a link to the product page.
  • Short explanations of size codes appear under the size buttons, only for the sizes this product has.
  • If a variant has its own description, it replaces the general product description when selected.
  • A product doesn't disappear from the catalog or drop to the end of the list, even when all its variants are sold out.

For the store team

  • Preorder is switched on per variant in its stock settings, with its own button label and note for the buyer.
  • Size explanations, their order and the product types they appear on are set in a table in the admin.
  • A variant's description is filled in on its own product card, and description replacement is enabled for selected product types.

How it works

  • Stock for each variant, for the current website's warehouse and minus reservations for unshipped orders, is sent to the page with its data, so size selection works without a server request on every click.
  • By default the platform removes sold-out variants from selection. We kept them selectable with a status label; otherwise the buyer could neither subscribe to a restock alert nor preorder.
  • For two-option products, valid combinations are calculated as the intersection of variant sets for the current selection. It doesn't depend on the order of options or on how they are shown, as buttons or as a dropdown.
  • Standard restock alerts work at the product level. We moved them to the variant level: the subscription stores the exact size, and the email links to the visible product page.
  • The preorder module originally considered only one product option. We extended it so preorder status is recalculated from the buyer's full selection.

Solution 7

B2B platform for dealers and partners

The store sells not only to private buyers but to a growing network of dealers, service shops and wholesale partners. We built a B2B platform around the catalog: each partner has its own prices, its own entry point and its own demand data, and new partners are onboarded without developers.

For partners

  • Tiered pricing: 15 price levels, from dealer discounts and wholesale to Gold, Silver and Bronze loyalty programs, about 100,000 individual prices across the catalog. After login, a partner sees its prices in the catalog, on product pages and in the cart.
  • Company accounts: employees work under a shared company account, and their orders go to the ERP automatically on that company's account.
  • Demand analytics in the customer account: top sellers and most viewed products, popular search queries, and the vehicles and engines searched most in the finder and garages. Partners use this to plan purchasing and assortment.
  • Tools for bulk ordering: a table catalog with up to 300 items per page and search by vehicle, engine or dimensions (Solutions 4 and 5).
  • A separate catalog website without prices for service shops and distributors, with one-click transfer to buying in the store.

For the store team

  • Partner onboarding without manual work: a registration form can be placed on any landing page, a new partner lands in its price group immediately and gets a personal welcome email, and managers receive a copy.
  • The ERP account number is set on the company card, and all orders from its employees go to it without manual matching.
  • Access to analytics is switched on for the right customer groups with one checkbox; the period and number of rows in reports are configurable.
  • Launching a new partner segment comes down to configuration: a new group, its own registration form and its own email.

How it works

  • The registration form is a widget that can be inserted on any page. It uses the platform's standard registration process, with the customer group, email template and copy recipients set on the fly, so all built-in protection and validation keep working.
  • The company account number is added to the order at the moment the ERP pulls orders through the API. The order data in the store itself stays unchanged.
  • The reports tab in the customer account is extensible: sales, finder and garage reports plug into it as separate blocks, and new reports are added the same way.

Solution 8

Back-office automation and sales analytics

More sales channels and partners mean more manual work for accounting and marketing: exports, reconciliations, looking for documents. We automated that routine: sales data flows to external systems on its own, documents are archived, and every return has a reason that can be analyzed.

For the store team

  • Data for the marketing dashboard: an API returns revenue and orders for any period, broken down by product type, brand, size and application. Marketing sees sales in its dashboard without exporting from the admin.
  • Automatic document archive: invoices and credit memos are generated as PDFs and saved to an archive, where the accounting system picks them up.
  • Exports with line items: order, invoice, shipment and return lists can be exported to CSV or Excel with product lines included, respecting current filters and selected rows.
  • Return analytics: when processing a return, the manager must choose one of 17 reasons, such as "didn't fit the application", "defect" or "order error". The reason is visible in the returns list and can be filtered.
  • Sales channel tracking: every order is tagged with its channel automatically (website, events, Amazon, eBay, Walmart) and goes to the matching account in the ERP.
  • A units-sold chart on the admin dashboard, next to the standard order and revenue charts.

How it works

  • The dashboard API calculates net revenue, excluding taxes, shipping and returns. When filtered by products, revenue is calculated per line item, so figures for one brand or size aren't mixed with the rest of the order. Responses are cached, so frequent dashboard requests don't load the store.
  • The line-item export is built into the standard export button in every list that needs it and runs page by page, so large exports don't hit memory limits.
  • The sales channel is detected from the order source: marketplaces through the marketplace integration module, events by payment method. Historical orders were tagged retroactively.
  • PDF documents are generated by the platform's standard mechanism, with the file name and archive folder configurable in the admin.

Solution 9

Part search by exact dimensions

Search by make and model works when the engine is a standard one. Engine builders and race teams often work with non-standard or modified engines: the block is bored out, the connecting rods replaced, and the vehicle model no longer says anything about which parts are needed. All that buyer has is measurements. We built a dedicated tool for them: part search by exact dimensions, with a tolerance down to hundredths of a millimeter.

For the buyer

  • The search page has three fields: length, diameter and wall thickness of the part, all in millimeters, each with a hint on what exactly to measure.
  • Each dimension has its own tolerance field with a typical value as a hint. The buyer decides how exact the match should be.
  • One dimension is enough. With several, the system finds parts that match all of them.
  • Results appear on the same page without a reload: a table with photo, part number and dimensions. The part number links to the product page, where the part can be bought right away.
  • A clear button resets the form, and if no dimension is filled in, the form says what to enter.

For the store team

  • The tool works across every part in the catalog that has dimensions, more than 9,000 items, with no separate data entry: dimensions come from specifications already filled in on products.
  • New products and changed dimensions reach the search automatically with regular catalog indexing.
  • The search is available through an open API, so it can be built into a mobile app, a partner website or a dealer tool.

How it works

  • Dimensions were stored on products as text like "54.000/54.013mm", sometimes up to seven pairs of values in one field. During catalog indexing we parse that text and write every value into its own numeric field in the search index, up to 42 fields per product.
  • Each dimension with its tolerance becomes a numeric range, and a part matches if any of its values falls into that range. Magento's standard search query builder couldn't combine conditions like these, so we wrote our own query building for the search engine.
  • The search runs on the search index, not the database, so answers come back fast even on a large catalog. Only products visible in search on the current website are returned.
  • The page is built as a separate UI component and talks to the server through the same API that is open to external systems.

Key Results and Business Value

  1. #1

    An online store built from scratch

    A 29,000-item catalog with vehicle search, online payment and two websites in one system, launched as a series of small releases without a risky switch-over.

  2. #2

    Nearly 7,000 online orders

    Since sales opened, the store has taken almost 7,000 orders, and it kept developing the whole time without stopping sales.

  3. #3

    About 200,000 part lookups

    Buyers looked up a part by vehicle or engine almost 200,000 times, and search-bar suggestions and dimension search cover the entire catalog.

  4. #4

    More than 2,000 vehicles in customers' garages

    Over a thousand buyers saved their vehicles and come back to their parts in one click, and the store sees which vehicles people shop for.

  5. #5

    Sold-out sizes no longer mean lost sales

    More than 400 restock subscriptions for specific sizes and dozens of preorders: demand for temporarily unavailable products stays in the store.

  6. #6

    More than 2,000 authenticity checks

    Buyers verified parts with the code from the packaging more than 2,000 times, and the manufacturer gained a direct line to the end owners of its products.

  7. #7

    A ready B2B model

    15 price levels and about 100,000 individual prices, company accounts, and partner onboarding without developers.

Features Delivered

  1. #1

    My Garage

    Saved customer vehicles, a header icon, an account page and a demand report.

  2. #2

    Related parts recommendations

    A carousel in the add-to-cart popup and a recommendation block on the cart page.

  3. #3

    Authenticity check and warranty

    Part verification by the packaging code, warranty registration, an owner section in the customer account and an API for code upload.

  4. #4

    Table catalog

    Part comparison by specification, column sorting, expandable rows with specifications in millimeters and inches.

  5. #5

    Parts finder

    By vehicle and engine, straight from the search bar, and through compatibility tabs on the product page.

  6. #6

    Size selection with stock

    Stock labels on every size, two-level variants, preorders and restock alerts for a specific size.

  7. #7

    Search by exact dimensions

    Part search by measurements with a tolerance, plus an open API for external systems.

  8. #8

    B2B platform

    Price tiers, company accounts, partner registration on landing pages and demand analytics in the customer account.

  9. #9

    Back-office automation

    Marketing dashboard data, PDF document archive, exports with line items, return reasons and sales channel tracking.

  10. #10

    Integrations

    ERP, marketplaces, payment gateway, email marketing, accounting system and a form automation service.

  11. #11

    Catalog website without prices

    A second website on the same platform with its own warehouse, its own finder and a path to buying in the store.

  12. #12

    Ready for AI search

    A machine-readable map of the store for ChatGPT, Claude and other AI assistants, updated automatically.

The technology we used

Platform
Magento 2 Open Source 2.4.7, PHP 8.2, MySQL 8.
Search and performance
OpenSearch and Elasticsearch with custom indexes and search queries, Varnish full-page cache, nginx.
Inventory and catalog
Multi-Source Inventory with separate warehouses for the two websites, configurable products with multi-level variants, flexible specification attributes.
Front end
Custom themes based on Luma, LESS, KnockoutJS and Magento UI components, RequireJS, responsive layout for mobile.
Integrations
Magento REST API with OAuth for the ERP, marketing dashboard and accounting system; marketplace integration for Amazon, eBay and Walmart; card and PayPal payment gateway; email marketing.
Customization architecture
More than 40 custom modules built through plugins, event observers, JS mixins and platform indexers without editing third-party code, plus reusable modules from our private package repository.
Infrastructure and process
Docker, GitHub with pull requests and code review, automated deployment through GitHub Actions and Deployer, separate development, testing and production environments.

Related services and case studies

Need a parts finder or a B2B store for your catalog?

If your buyers need the exact part for their vehicle, engine or measurements, or your dealers still order by email, we can show how this would work on your catalog. We start with a fixed estimate and reply within one business day.

Need something similar? Let's discuss.

Tell us what you want to build, and for whom. If we're a fit, you get a clear next step. If not, we'll tell you.

Write us
  • Reply within one business day
  • Fixed estimate before we start
  • No commitment