VISHNU JEWELLERS
Jewellery Inventory Management System
Report Generation
Catalogue Search
Dead Stock Discovery
Duplicate SKU Risk
A mid-scale jewellery business was running its inventory, order tracking, and customer management entirely on spreadsheets and paper registers. This caused duplicate SKU entries, no audit trail on stock movements, design photos stored in WhatsApp chats impossible to retrieve reliably, reports that took 3–5 hours to compile manually, and stone specifications mixed into product records making reuse impossible.
We built a production-deployed inventory management system that manages SKUs, orders, customers, vendors, stone specifications, and business analytics from one unified interface. Next.js serves as a BFF (Backend for Frontend), keeping credentials server-side while enabling server-side PDF generation. The cataloging process itself uncovered over ₹3 lakhs in forgotten dead stock.
Under the Hood
Next.js as BFF (Backend for Frontend)
All API calls route through Next.js API routes rather than exposing the backend directly. This keeps credentials server-side, allows request transformation, and enables server-side PDF generation in a single deployment unit.
Secure Image Pipeline
Raw file → base64 → API route → Buffer → GCS upload → Stored URL. Retrieval uses signed GCS URLs per request with client-side caching. No public image exposure, no credential leakage to browser.
Stone SKU (SSKU) System
Stone specifications are managed as separate entities, not buried inside product records. A single stone spec can be referenced by hundreds of jewellery SKUs without duplicating data — updating the stone record propagates everywhere.
Debounced Multi-Field Search
Client-side search against the full in-memory SKU list with 300ms debounce. Checks query against SKU ID, name, description, design owner, and dimensions simultaneously — sub-5ms search with no backend round-trip.
- +SKU management with 10+ filter dimensions and composable search
- +Stone SKU (SSKU) system decoupling stone specs from product records
- +Order management linking SKUs, customers, labour details, and pricing
- +Server-side PDF report generation — customer and internal variants
- +Monthly analytics dashboard with rolling 12-month order volume
- +Customer and vendor management with UUID-referenced entities
- +SKU duplication for creating design variants
- +Secure image pipeline with signed GCS URLs and client-side caching
Why We Did
What We Did
Every architectural decision has a reason. Here are the ones worth explaining.
Why Context + useReducer over Redux Toolkit?
The state shape is predictable — SKUs, orders, customers, vendors, specs, stones are each flat arrays. Redux would add ~2000 lines of boilerplate for no real benefit at this scale. The reducer pattern provides the same dispatch/action model with zero extra dependencies.
Why client-side search over server-side?
At the current scale (~1,000–5,000 SKUs), loading all SKUs into memory and filtering in-browser gives sub-5ms search with no backend round-trip. If the catalogue grows to 50,000+, this would need revisiting.
Why Next.js as BFF instead of separate Express server?
Next.js collapses the BFF layer and frontend into one deployment unit. API routes handle image upload, PDF generation, and auth without maintaining a separate service.
I had no idea we had so much stock sitting forgotten in our store. The cataloging process The Beyond Horizon did for us uncovered over ₹3 lakhs in inventory we did not even know existed. The website now brings customers who would never have walked through our door.
Titu Singh
Owner, Vishnu Jewellers
Ready to Build Something Like This?
Let's talk about your project.