Spare parts is one of the best marketplace categories in MENA right now, and one of the hardest to build well. Demand is constant — cars break regardless of the economy. Supply is fragmented across thousands of small shops and importers. And the buyer's core problem isn't price. It's "does this part fit my car?"
I've shipped a production automotive marketplace — Ajza, five transactional flows on one backend, serving web dashboards and three native apps, fully bilingual Arabic/English. This post covers what makes spare parts different from generic e-commerce, and the architecture decisions that matter.
Why spare parts is not "e-commerce with car parts"
A generic storefront fails at three things the parts buyer needs:
Fitment. A brake pad isn't a product; it's a product for a 2019 Hyundai Elantra 1.6L. Your catalog needs a vehicle model (make → model → year → trim/engine) joined against part compatibility. Get this wrong and your return rate destroys unit economics before you ever reach scale.
Part identity. The same part exists as an OEM number, several aftermarket cross-references, and a colloquial Arabic name the mechanic actually uses. Search has to resolve all three. This means a normalization layer over part numbers and a bilingual synonym index — Arabic search that only matches exact strings is useless in a market where the buyer types "طرمبة بنزين" and the catalog says "fuel pump".
Trust in condition. New, used, and refurbished parts coexist in the same market with wildly different prices. The marketplace has to make condition, warranty, and seller reputation legible — otherwise buyers default to the shop they already know and your platform adds no value.
The three-surface architecture
Like any real marketplace, a parts platform is at minimum three products on one backend:
- Customer surface — vehicle-first search ("my car" garage saved to the account), availability, delivery time
- Vendor surface — inventory sync, order management, pricing, payouts
- Operations surface — dispute resolution, catalog governance, financial reporting
The one that kills spare parts marketplaces specifically is catalog governance. If every vendor uploads their own free-text listings, you get twelve differently-spelled duplicates of the same alternator and fitment data you can't trust. The platform must own the canonical catalog — vendors attach offers (price, quantity, condition) to platform-owned part records. This is the single most important schema decision you'll make.
Vehicle (make/model/year/engine)
└── Fitment ── Part (canonical, platform-owned)
└── Offer (vendor-owned: price, qty, condition, warranty)
Inventory is a distributed-systems problem
Vendor stock changes offline — a walk-in customer buys the last water pump while your platform still shows "in stock". You handle this with:
- Reservation with TTL at checkout, not naive decrement — the order holds stock for a bounded window pending vendor confirmation
- Vendor confirmation SLA — auto-cancel and re-route to the next best offer if the vendor doesn't confirm in time
- Idempotent order and payment operations — retries must never double-charge or double-reserve. I've written about the ledger patterns behind this in Handling money correctly
On Ajza, order state machines with explicit transitions (placed → confirmed → picked → in-transit → delivered, with compensating paths at each step) were the difference between an operations team that scales and one drowning in WhatsApp screenshots.
MENA-specific requirements you can't skip
- Arabic RTL as a first-class citizen — data model, search, and UI. Retrofitting RTL is far more expensive than building with it. (More in my marketplace-in-Egypt guide.)
- Cash on delivery — still a large share of MENA transactions. COD changes your risk model: verification, driver cash reconciliation, and refund flows all differ from card-first markets.
- Local payment gateways alongside cards, with payouts that respect how small parts shops actually bank.
- Delivery orchestration — parts are heavy, fragile, and urgent. Same-day city delivery with live tracking is a feature buyers will switch platforms for; on Ajza we ran live rider tracking over Socket.IO.
Build vs. adapt
Founders sometimes ask whether Shopify/WooCommerce plus plugins can do this. For a single-vendor parts shop — yes, start there. For a marketplace — multi-vendor offers on a canonical fitment catalog, reservation logic, vendor payouts, COD reconciliation — you'll spend more bending a storefront platform than building the right system, and you still won't own the data model that is your actual moat.
The pragmatic stack I use: NestJS + PostgreSQL for the backend (relational integrity matters when fitment is the product), Next.js for web surfaces, Flutter for the native apps so customer, vendor, and driver apps share one codebase discipline — one backend, every device. That's the same architecture running Ajza's five marketplaces today.
Where to start
If you're validating a spare parts marketplace idea, don't start with the app. Start with one city, one vehicle segment, and a catalog for the 500 fastest-moving parts. Prove that vendors will keep offers current and that buyers convert on fitment-verified search. The platform architecture above is what you build once that's true.
Building something in this space — in Egypt, Saudi Arabia, or the wider region? Tell me about it. I've made the expensive mistakes already, and the first call is free.