Project background and the high-touch commerce model
Bhatkal Time Luxe serves the luxury watch retail market, a domain where high-value transactions require human negotiation rather than automated checkout. Standard eCommerce platforms, which enforce rigid "add to cart to payment" flows, failed to support the necessary trust-building and authenticity verification inherent to this industry.
We replaced the traditional payment gateway with a WhatsApp-based concierge model. The storefront acts as a discovery and qualification engine, building a structured order message that the customer then sends to the retailer to initiate a conversation. This choice prioritizes high-conversion negotiation over the friction of an automated payment gateway that does not reflect the client's actual business process.
Architectural evolution
The project originated as a Create React App (CRA) frontend paired with an Express backend. We identified this split as the source of unnecessary operational complexity, specifically regarding CORS configuration and API contract management. During Phase 2, we consolidated the entire stack into a single Next.js 16 App Router monolith.
This consolidation removed a significant deployment surface, replacing two build pipelines with one. We traded the steeper learning curve of the App Router for a drastically reduced surface area for cross-service bugs and integration overhead.
Mobile and desktop component strategy
Rather than forcing a single responsive layout, we implemented separate component trees for mobile and desktop views, switching at a 1024px breakpoint via a `useIsDesktop` hook. This decision accepts the cost of building every feature twice to ensure high-fidelity interactions tailored to the device: a glassmorphic navigation for desktop and a bottom-tab-bar pattern with a persistent WhatsApp FAB for mobile.
To mitigate the maintenance burden, we avoided a third component tree for tablets. Instead, we layered tablet-specific enhancements onto the mobile components using `md:` breakpoint modifiers, providing a two-column layout without doubling the codebase again.
Operational tooling and administrative control
The admin back office is a JWT-authenticated SPA-like shell under `/admin/*`. It enables non-technical staff to manage product CRUD, homepage curation, and order tracking independently. We implemented a reference code system (e.g., `BTL-RLX-001`) that remains immutable across product renames, providing support staff with a stable identifier for order reconciliation.
Engineering decisions and tradeoffs
- Shared Pricing Module: We consolidated cart and single-product checkout logic into a single module to prevent calculation drift, a common bug in eCommerce systems with multiple purchase paths.
- Image Pipeline: We implemented an env-var-toggled delivery layer. Cloudinary serves as the authoritative storage, while Imgix is an optional, swappable delivery layer. This allows for immediate fallback without code changes.
- Rate Limiting: We shipped an in-memory per-IP limiter with explicit documentation for the eventual migration to Upstash Redis. We chose to defer infrastructure complexity until multi-instance deployment requirements were met.
- Cart Identity: We opted for cookie-based cart persistence rather than full user accounts to reduce friction for the initial browse-to-negotiate flow.
Lessons learned
Collapsing service seams early proved effective in removing entire classes of integration bugs. The decision to maintain two UI trees remains a high-cost, high-benefit tradeoff; future iterations should continue to weigh this against the maintenance surface. Finally, deferring infrastructure investment is a valid strategy provided the limitations are explicitly documented within the codebase, as demonstrated by our approach to rate limiting.