E-Commerce
A high-performance e-commerce rebuild for organic gardening supplies, featuring a Shop-by-Pest finder, Razorpay payments, and automated Shiprocket logistics.
01 · Stack
| Layer | Technologies | Key libraries |
|---|---|---|
| Frontend Framework |
|
|
| UI & Styling |
|
|
| State Management |
|
|
| Backend / Runtime |
|
|
| Database & Cache |
|
|
| Authentication |
| · |
| Hosting & Infrastructure |
|
|
| Integrations & APIs |
|
|
Documented as a first-class artifact in docs/DESIGN_SYSTEM.md, covering colour, motion, component recipes, and accessibility rules · so the system is reviewable independently of the code that implements it.
Heavily modularised, composing utility classes through clsx and tailwind-merge with variants handled by class-variance-authority.
The landing hero renders a React Three Fiber leaf-particle canvas for desktop visitors on a good connection, while mobile, save-data, and reduced-motion visitors receive a roughly 2 KB CSS and SVG leaf layer instead. The visual intent survives; the performance cost does not.
Zustand holds client-side cart state while Server Actions own every mutation that must be trusted · cart validation and order creation both resolve server-side.
Mobile-first, with a slide-out cart drawer and a deliberately multi-step checkout (address, shipping, payment) that reduces the cognitive load per screen and, with it, cart abandonment.
Turbopack in development, server-side rendering in production, and a custom image pipeline (scripts/process-images.ts) that optimised 81 source photographs migrated from the legacy site.
Serverless, built on the App Router with Server Actions as the mutation layer.
Firestore as the document store, seeded from a Base/ folder holding the extracted legacy WordPress data. Migration scripts parse that source into Firestore documents and a local catalog.json fallback, so the catalogue provably matches the original business data.
Prices are never trusted from the client. The checkout payload carries only { slug, qty }; the backend re-reads every price from Firestore and recomputes the order total server-side before the payment gateway is initialised. Tampering with the browser payload changes nothing.
Firebase Auth with custom claims, and admin access gated at three independent layers so no single bypass grants entry.
Two webhook receivers carry the asynchronous half of the order lifecycle.
04 · Features
A parsed taxonomy mapping 26 distinct pest and disease tags directly to the organic products that treat them. Customers arrive knowing their problem, not a product name · so the catalogue is indexed by the problem.
Shiprocket integration providing live PIN-code serviceability checks during checkout, one-click AWB generation, and automated tracking webhooks · with a mock shipping mode so the whole flow is testable locally.
A role-based panel with a Kanban order board, PDF invoice generation, real-time KPI metrics, stock management, and low-stock alerts.
05 · Standout engineering
Every project has two problems that determined whether it worked. These were theirs.
Stock decrement logic runs inside Firestore transactions and bails out unless the order is still pending. The browser success callback and the Razorpay webhook can therefore both fire · as they routinely do · without ever double-decrementing inventory.
Automated parsing of unstructured legacy WordPress exports (Products.csv, loose text files) into strict JSON schemas and Firestore documents, making the product catalogue and policy pages provably identical to the original business data rather than a manual re-entry.
06 · Engineering practice
├── Base/ # Legacy WordPress export (source of truth) ├── docs/ │ ├── PRD.md │ └── DESIGN_SYSTEM.md ├── scripts/ # Migration, seeding, image optimisation ├── src/ │ ├── app/ # shop, admin, api routes │ ├── components/ │ ├── data/ │ │ └── catalog.json # Offline development fallback │ ├── lib/ # pricing, taxonomy, commerce │ └── types/ ├── firestore.rules └── next.config.ts
A custom npm run verify script executing 49 assertions across the catalogue and core business logic, with pricing integrity · that a tampered payload cannot change an order total · as an explicit test rather than an assumption.
Vercel with automated build steps, degrading gracefully to the local JSON catalogue when Firebase credentials are absent so a fresh clone runs without secrets.
07 · Impact
Replaced a slow legacy WordPress installation with an edge-optimised, heavily cached Next.js application.
Razorpay and Shiprocket together convert a manual, phone-and-message order process into an automated pipeline that absorbs traffic spikes without proportional staff effort, and the Kanban board compresses the internal handling time per order.
08 · Interface
Contact
The best fit is a business that needs a system to hold up under real use · not a template with your logo on it.
