Parts commerce breaks most of the assumptions built into generic e-commerce platforms. A wrong part is not a return — it is a stranded vehicle, an idle lift, or a production line waiting. That changes what your first version has to get right.
This is the checklist I work from, drawn from building Ajza (automotive parts and services, Saudi Arabia) and MONTRA (B2B elevator parts, Egypt).
Ship in version one
1. Compatibility as structured data
If a buyer cannot filter by their vehicle or machine, your catalogue is a text search with extra steps. Before any screen exists, decide how a part, a fitment record and a supplier price relate to each other.
Concretely, in version one you need:
- A fitment model — make, model, year range, engine or machine spec — attached to products, not typed into descriptions
- A "my vehicles" concept so a returning buyer never re-enters it
- Search that filters by fitment first and keyword second
Everything else in a parts platform can be added later. This cannot: retrofitting compatibility into a live catalogue means re-entering your entire product data.
2. Part identity that survives real life
The same physical part has an OEM number, one or more aftermarket numbers, a supplier's internal SKU, and a name that varies by region and language. Version one needs a single canonical part record with alternate identifiers attached to it, so two suppliers listing the same component are visibly listing the same component.
Skip this and you get a catalogue where the same part appears eleven times at eleven prices with no way to compare them — which is exactly the problem your buyers came to you to escape.
3. Arabic search that finds Arabic
If you serve Arabic-speaking buyers, normalise alef and hamza forms, taa marbuta, yaa and diacritics before indexing. Without it, a buyer searching فلتر and a listing spelled slightly differently never meet, and your catalogue looks empty when it is full.
This is a small piece of work in version one and an embarrassing bug report in version three.
4. A quotation path, even a simple one
Rare, heavy and high-value parts get negotiated. If your platform has no request-for-quote flow, every one of those orders leaves the platform for WhatsApp — and with it your commission and your record of what happened.
Version one does not need a full negotiation engine. It needs: a buyer can post a request, suppliers can respond with a price, the buyer can accept, and the accepted offer becomes a real order. That is enough to keep high-value trade inside the system.
5. Order splitting, if you have more than one supplier
A realistic basket comes from several warehouses. Decide early whether your platform models this. If it does, one customer order becomes several supplier sub-orders with independent fulfilment states, while the buyer still sees a single order and a single status.
If you defer this, every multi-supplier order becomes a manual dispatch job for someone in operations. That person becomes your scaling limit within months.
6. Money movements as ledger entries
Even in version one, if you hold money at any point — wallet balances, deposits, commission withheld from a payout — record movements as append-only entries and derive balances from them. Do not store a balance you mutate.
This is maybe a day of extra work at the start. It is the difference between answering a supplier dispute with data and answering it with an apology.
7. A supplier surface people will actually open
The most common way a parts marketplace fails is not technical: suppliers never adopt the dashboard, so the catalogue goes stale and buyers stop coming back. Version one needs bulk upload (they have spreadsheets), a clear order queue, and a payout statement they can reconcile without calling you.
If a supplier has to log in more than once a day to do their job, they will not log in at all.
Defer to version two
These feel urgent and are not:
- Native mobile apps for buyers. A fast, server-rendered web storefront serves buyers well and starts earning search traffic immediately. Supplier and driver apps are a different question — those often do earn their place early.
- Self-serve supplier onboarding. Onboard your first twenty suppliers personally. You will learn more from those conversations than from any analytics dashboard, and manual onboarding is faster than building the flow.
- Loyalty, points and gamification. Parts buyers are repeat buyers because you have the part, not because of a badge.
- Advanced analytics. In version one you need to know orders, revenue, and which searches returned nothing. That last one is your product roadmap.
- Multi-currency. Unless you are genuinely cross-border on day one, this is complexity without a customer.
- AI-anything. There are real applications — Qooty uses computer vision to read retail flyers, which removed manual data entry entirely — but that was solving a specific, expensive, measurable problem. If you cannot name the problem, it is a feature looking for a use.
The pre-build homework that saves the most money
Two things you can do before hiring anyone, which will measurably reduce your build cost:
- Clean your product data. Consistent naming, consistent units, compatibility notes in a separate column rather than buried in the description. Import is a real workstream; cleaner input makes it shorter.
- Write down the current order journey. How does an order reach you today, who touches it, and where does it stall? That document is worth more to an engineer than a competitor's website.
If it helps, the Project Brief Generator walks through exactly those questions and produces a structured document in about three minutes.
What this looks like built
If you want to see the shape of a finished parts platform — compatibility catalogue, quotation flow, multi-supplier routing, wallets and payouts — the spare parts marketplace development page walks through the full scope, and the Ajza and MONTRA case studies show two different answers to the same problem.
Or book a free 15-minute call and bring your current order journey. That is enough to scope a first version.