Case Study · Marketplace · India
India’s automotive spare-parts trade runs on phone calls, WhatsApp and memory. A client wanted to build the first serious multi-vendor marketplace for it. The hard part was never the technology — it was that the industry had no shared product language. Solving the catalogue problem first is what made the marketplace work.
What they thought the problem was
“We need a marketplace platform.”
Which is a technology brief. And if I had accepted it as a technology brief, we would have built a competent e-commerce site into a market that could not use it.
What the problem actually was
The spare-parts industry does not have a product catalogue problem. It has a product identity problem.
- No standardised SKU structure existed. The same part is called four different things by four different distributors. Without a shared taxonomy, a marketplace is just a pile of unmatched listings and no buyer ever finds anything.
- The real search is not textual, it’s mechanical. Nobody searches for a part number. They search for “the thing that fits my 2016 model, this variant.” Make → Model → Variant → Year filtering had to be precise and fast, or trust would break on the first wrong result.
- Vendors would not adopt anything with friction. Distributors managing thousands of items in spreadsheets will not hand-key inventory into a web form. If stock sync was hard, the catalogue would go stale within a month and the platform would die quietly.
- Multi-vendor settlement is a trust product, not a payments feature. Forty vendors sharing one checkout need transparent commission logic and reliable payouts, or they leave.
The reframe
This was not “build a marketplace.” It was “create the shared product language an industry never had, then build commerce on top of it.” The catalogue was the product. The storefront was the interface.
The three moves that mattered
1. Standardise the catalogue before writing the storefront
A centralised SKU and product taxonomy was designed first, with batch upload paths so a vendor’s existing spreadsheet could become live inventory in one step rather than a data-entry project.
2. Build search around how mechanics actually think
Dynamic vehicle-based filtering — make, model, variant, year — with the part-fitment relationships modelled properly underneath. This is the feature that decides whether a buyer returns.
3. Treat launch as part of the build, not a phase after it
On-page SEO, schema markup, performance work and pre-launch campaigns were executed alongside development, not bolted on afterwards. A marketplace that launches invisible has to buy every early user twice.
The stack: React and Next.js front end, Node and Express back end, MongoDB, AWS hosting, with Shiprocket for logistics and Razorpay for multi-vendor settlement.
What changed
The 60% organic growth inside 90 days is the figure that validates the sequencing decision. That is not the result of a marketing campaign; it is the result of a catalogue architecture that search engines could read and a launch plan that existed before the code was finished.
The transferable principle
Marketplaces do not fail on technology. They fail on liquidity and trust — and both are decided by data structure. If your category has no shared vocabulary for what it sells, you are not building a platform, you are building a standard. Budget accordingly, and do it before the interface.
Building a platform, marketplace or category-defining product? The expensive mistakes get made in the first six weeks, not the last six.
I led this engagement through Cuneiform Consulting, the AI-first digital consulting company I founded — from product strategy and architecture through launch. Client name withheld under confidentiality. All figures as reported at the close of engagement.