~/case/luminique← /work
$cat README.md
/02

Luminique

A luxury fine-jewellery storefront — server-rendered catalogue with shareable faceted filters, per-piece variant and engraving customisation, wishlist, and a full cart-to-returns checkout.

year
2026
role
Frontend Developer
duration
6 months
live
> stack
  next.js · react · typescript · tailwind css · framer motion
$cat summary.md

A premium storefront for a fine-jewellery brand, built on the Next.js App Router. Customers browse curated collections, narrow them with faceted filters that live in the URL, customise a piece's metal, stone, and engraving, then move through cart, checkout, and post-purchase returns. The catalogue is server-rendered for SEO and freshness; the brand's content — banners, collections, testimonials — is CMS-driven, and a commerce API backs inventory, pricing, and orders.

$ls features/
  • 01Server-rendered catalogue across rings, earrings, pendants, necklaces, bracelets, and more
  • 02Faceted filtering — metal, stone, price, badges — encoded in shareable, bookmarkable URLs
  • 03Product detail with variant selection (metal colour, stone, size) plus custom engraving
  • 04Persistent cart and wishlist with guest support that syncs to the account on sign-in
  • 05Mobile-OTP auth and an account hub: profile, addresses, orders, returns, reviews
  • 06Checkout with coupons, multi-address shipping, order tracking, and invoice download
$cat challenges.md
#01Filters that are shareable but server-resolved

URLs use human-readable slugs (?metal=gold) while the API speaks in IDs. The catalogue had to map slugs ↔ IDs on the server for SEO-clean links, yet still feel instant as users toggle facets on the client.

#02Fresh inventory, never stale

Jewellery prices and stock change from the admin side and must show immediately. Next.js, the browser, and any CDN in front all want to cache server responses — exactly what a live catalogue can't tolerate.

#03One product, many configurable dimensions

A single piece varies by metal, metal colour, stone, size, and engraving text — each combination with its own availability and price. That state has to stay coherent from the product page all the way through checkout.

$cat approach.md
01Server slug↔ID resolution, client-side toggles

The category page resolves filter slugs to API IDs server-side and renders the first paint SEO-ready. A `useFilters` hook then handles toggles on the client, debounced with an AbortController so rapid changes cancel stale in-flight requests instead of racing.

02Singleton API client with enforced no-cache

A single shared Axios instance with a request interceptor stamps no-cache / no-store on every server request, and pages run `force-dynamic`. One instance instead of per-call clients cut memory and overhead while guaranteeing every shopper sees live pricing.

03Variant state modelled end-to-end in TypeScript

Variant, size-chart, and engraving selections are typed from the product page through Context-based cart and wishlist, so the chosen configuration — and its price — carries intact into checkout. Guest carts and wishlists migrate to the account on login.

$git log --oneline
  • 1b9f4a2chore: Next.js App Router + Tailwind scaffold
  • 7c2e8d5feat: catalogue + URL-based faceted filters
  • a4d1f63feat: product detail, variants, engraving
  • 3f6c9b1feat: cart, wishlist, guest sync
  • d2a7e40feat: mobile-OTP auth + account hub
  • 9e5b3c8feat: checkout, coupons, returns, invoices
  • productiondeploy: storefront live
$cat outcomes.md
  • Full storefront flow shipped: browse → filter → customise → cart → checkout → returns
  • Shareable, SEO-clean filter URLs with live, never-stale pricing
  • GA4 ecommerce tracking and CMS-driven banners, collections, and testimonials
$ls ../
pritesh@portfolio: ~/case/luminique$
© 2026 Pritesh Mendapara · Frontend Developer · built in surat