Central Gebeya
Auto-parts marketplace with a platform-owned catalogue
Buying a car part in Ethiopia means knowing whether it fits your vehicle, and vendors describe the same part differently, with different names and different part numbers. Nothing is comparable.
Decision
The platform owns the product catalogue. Vendors do not create listings. They place offers against platform-owned master products, so one physical part has one canonical record with many competing offers beneath it.
Why
That is what makes price and quality comparable across vendors.
Cost
The platform carries catalogue maintenance forever, and every new part needs a master record before anyone can sell it, which puts a person in the critical path of vendor onboarding.
This was the hardest design problem in the project.
Decision
Fitment is scored out of 5 across name, model, year, part number and other metrics, rather than matched yes or no.
Why
Fitment data is incomplete, and requiring all four to agree returns nothing for most searches, so a graded score surfaces near matches with their uncertainty visible.
Cost
A confident 3 out of 5 that does not actually fit damages trust more than an empty result would.
Offers rank by price, then vendor rating, then stock.
PostgreSQL was chosen over MySQL because the master-product model is relational to its core, with one part relating to many vehicles, many offers and many orders, and offer ranking is a sorted join. The courier and delivery flow was built end to end, and the app is tuned for slow mobile connections, which is the normal condition for its users.
Stack
- React Native: Native mobile experience on Android.
- Expo: Build pipeline and device testing for the mobile app.
- Node: Backend runtime for marketplace APIs.
- Express: REST routing for catalogue, offers and orders.
- PostgreSQL: Relational joins for master products, fitment, offers and orders.
- Android: Primary target for the Ethiopian parts market.
Screens
