The client sold luxury watches without a website. Every enquiry ran through WhatsApp: a customer asked for a Rolex, the shop scrolled its own photo library, and sent a burst of images back. There was no way to browse, no way to compare two pieces, no way to filter by brand or size, and no link to send anyone. YR Luxury is the web app I built to replace that conversation with a catalogue — 7,000+ watches across 45+ brands that a customer can explore on their own, in Dutch or English, and only reach for WhatsApp once they know exactly what they want.
The technical problem
Three constraints shaped every decision.
- Scale on the client. Seven thousand products with images is not a list you paginate on a server you do not have. The whole catalogue had to stay searchable and filterable in the browser without the page stalling on every keystroke.
- Unstructured source data. Brand, model, size and variant were not fields — they were free text inside product titles, written inconsistently over years. Filtering by brand is trivial once you have a brand column; the work was deriving one that could be trusted.
- No sales team on the site. The shop's expertise lives in a chat. The site had to narrow thousands of options down to the handful worth asking about, then hand the customer to WhatsApp with the context already attached.
How I solved it
- Brand normalisation: a keyword-matching resolver that reads a messy product title and returns a canonical brand across 40+ names, tolerating abbreviations, spacing variants and misspellings. Everything downstream — filters, brand pages, breadcrumbs — depends on it, so it runs once at ingest rather than per render.
- Faceted filtering: brand, size, men's/women's, diamonds and quality, combined freely and evaluated client-side against a normalised index, with search debounced so typing never blocks the grid. Paging keeps the DOM small while the filters still see the whole catalogue.
- A real page per watch: its own URL, image gallery, specifications, shipping and payment options and breadcrumbs — so a product can be linked, shared and indexed, which is precisely what a photo in a chat can never be.
- Bilingual routing: Dutch and English across the interface and the product routes, because the shop sells to both markets.
- Favourites: a shortlist the customer assembles while browsing and sends over as one message instead of thirty screenshots.
- WhatsApp hand-off: deep links that pre-fill the product, so the enquiry arrives with the watch already identified and the conversation starts at the price rather than at “which one?”
- Admin dashboard: the owner manages the catalogue — status, source, live counts — through an interface rather than through Firestore.
What it changed
The shop stopped being a photo album behind a phone number. Customers self-serve through 7,000 products and arrive in the chat already decided, which turns WhatsApp from a browsing tool into a closing tool.
Stack
React · Vite · Tailwind CSS · Firebase / Firestore · Firebase Hosting · React Router · i18n (NL / EN)
