A parts network for the cars India stopped making.
Chevrolet left India in 2017. Ford left in 2021. Roughly a million vehicles were orphaned between them, and lakhs more are scrapped every year because one part could not be found. The competitor here is not Amazon. It is giving up and selling the car for scrap.
- Our role
- Co-partner, design and build
- Status
- In design, 2026
- Surface area
- 5 products · 161 screens
- Market
- India, national
One choice, and every screen follows from it
SPARRAPS is not a marketplace where customers choose between sellers. It is a single retailer with an invisible supply network — the customer’s entire relationship is with the platform, and they never learn which godown their part came from. Six rules fall out of that decision, and every screen in five products obeys them.
- Customer and vendor never meet. No names, numbers, chat or vendor branding anywhere in the customer app.
- The platform sets every price, centrally. Vendors accept or reject. No bidding, no negotiation, no per-vendor pricing.
- Nothing is charged before approval. Payment happens only after the customer sees photographs of the actual part and accepts it.
- Ratings are private to the vendor and the platform. Never public social proof.
- Trust comes from the badge. With no public reviews, the assurance badge and the return guarantee carry the entire trust burden.
- “Vendor” is internal vocabulary. It never appears in customer-facing copy — the customer’s relationship is with the platform.
The hard problem is not the catalogue. A spare parts godown holds lakhs of individual parts, and finding one means someone physically digging through shelves — which only happens if a sale is certain at the end of it. So the catalogue can never be complete, and “no results” is not an error state. It is where the product begins.
We designed the not-listed request as a primary flow rather than a fallback, and built sequential routing so a request walks the network one vendor at a time instead of triggering a bidding war. Orphaned brands — Chevrolet, Ford, Datsun, Fiat, Opel, Daewoo — became the front door rather than a long tail, because they are the searches nobody else can answer.
Five products came out of it: a customer app and a responsive web front, a vendor app and a vendor portal, and an admin console that fixes every price centrally. Four of them can never mention the fifth, which is the constraint that made the design system necessary rather than nice to have.
161 screens, one design system
Four of these can never acknowledge that the fifth exists. That is the constraint that made a shared system necessary rather than merely tidy.
Customer app
iOS and Android. Search, request, approve, track.
Customer web
Responsive front, built for organic search entry.
Vendor app
Accept or decline, photograph the part, dispatch.
Vendor portal
Stock, settlements, performance — vendor-side only.
Admin console
Central pricing, routing rules, assurance decisions.
In design, and we will say so
SPARRAPS is in design. The operating model, the design system and all 161 screens are specified; the application code is not yet written, and nothing is handling live traffic. We are saying so plainly because the alternative — writing this page in the past tense — is a claim a prospective client would check and find false.
What is finished is the part that decides whether the rest works: the model. If you want to see how that gets made, the discovery process on every project we take is the same one that produced it.
How discovery worksFour of our practices, on one product
Have a product at this stage?
The most valuable work on SPARRAPS happened before any code existed. If you are at the point where the model is still being argued about, that is exactly when to talk to us.