Custom Jewellery ERP Software: A Socilet Case Study
Built by Dheeraj Tagde, Founder of Socilet
A sale at the jewellery counter is only the beginning. That same transaction touches stock, discounts, GST, payment records, customer history and, sometimes, a return weeks later. If those parts do not agree, the business owner is left reconciling the difference.
For this client, I built a custom jewellery ERP around those connected workflows—not just a screen that prints a bill.
The system brings together point-of-sale billing, store-wise inventory, godown transfers, purchases, ledgers, GST reporting and customer access. It was developed for the client's operating requirements rather than presented as an off-the-shelf package.
There was also an important commercial distinction: zero advance payment for development work. The client funded required resources and APIs upfront; payment for development work followed completion.
Watch the project walkthrough alongside this case study to see the application behind the story.
Project at a glance
- Creator: Dheeraj Tagde, Founder of Socilet.
- Engagement: Custom jewellery ERP development for an Indian retail and wholesale operating context.
- Coverage: Billing, inventory, multiple stores, godown operations, purchases, ledgers, reports and customer-facing access.
- Development payment: After completion; only resources and API costs were paid in advance.
- Relationship: Approaching one year, with a very happy client, according to Dheeraj's account of the engagement.
- Client confidentiality: The client name and live application address are not disclosed.
The brief: connect the counter to the rest of the business
The scope needed to accommodate more than a straightforward retail checkout. A jewellery business may need different pricing rules across stores, wholesale transactions, stock movement between a godown and a shop, customer bookings, and purchases from suppliers.
The real challenge was making those workflows fit together without treating each one as a separate application.
This meant answering practical questions throughout development:
- Which store owns the stock being sold or transferred?
- How should item discounts, bill discounts and tax affect the final amount?
- What happens when an item is returned, exchanged or refunded?
- Which records should a salesperson see, and which belong to an administrator?
- How can the same transaction be presented on a full-size invoice and a compact thermal receipt?
These questions shaped the system's modules, access rules and calculations.
What I built
1. Jewellery billing software for retail and wholesale workflows
The POS supports product selection, barcode-assisted entry, customer details and salesperson attribution. Transactions can record cash, card and online payments, including split payments.
Pricing follows a defined sequence: MRP, item discount, bill discount, taxable amount, GST and grand total. Monetary calculations use two-decimal precision, with grand totals rounded to whole numbers.
Store-specific invoice prefixes, bill history, PDF output and A4 or thermal printing make the billing flow useful beyond the checkout screen. Estimates, advance bookings and retail/wholesale workflows are also included.
The point was not simply to generate a receipt. It was to retain the context needed to understand the sale later.
2. Jewellery inventory software with store-wise stock
The product catalogue supports design numbers, categories, companies, barcodes, images and stock quantities. It also contains jewellery-specific fields for metal type, weight, purity, making charges, stone charges and hallmark information.
Stock records are associated with stores. Opening stock, current stock and minimum-stock alert thresholds give the business a structured inventory model.
Excel import and export tools support catalogue maintenance. Product history connects relevant events such as creation, movement, sales and returns, making inventory more than a list of product names.
These are supported data fields and workflows; the system is not presented as a jewellery CAD tool or a manufacturing/karigar management suite.
3. Godown transfers and multiple-store operations
Moving an item from a godown to a shop is a business event that needs its own record.
The ERP includes stock-transfer batches, source and destination stores, quantities, transfer references and printable transfer challans. Store and firm selection help keep operational records in the appropriate business context.
Multiple-firm support also accommodates distinct invoice branding and reporting requirements. Store-level access rules limit which locations non-admin staff can work with.
4. Purchases, supplier ledgers and customer records
Purchases sit alongside sales rather than outside the application. Purchase entries support supplier details, bill references, tax fields, payment information and item-level records.
Customer and supplier ledgers provide a place for party details and related transactions. Customer lookup, customer address capture and salesperson management support the administrative work around a sale.
This is particularly relevant to custom ERP development: the purchase desk, the sales counter and the owner do not all need the same view, but they need records that can be related to one another.
5. GST reporting, exports and financial review
The application handles GST rates and CGST, SGST and IGST fields, together with HSN/SAC information. It includes GSTR-1 and GSTR-2 reporting/export workflows, sales reports and downloadable data.
Reports can be reviewed in the context of stores and firms. PDF and spreadsheet exports support sharing and subsequent review.
The purpose is to make transaction information available for accounting review—not to replace an accountant's judgement or guarantee statutory compliance without checking the underlying entries.
6. Returns, exchanges and cash refunds
A return changes more than the customer-facing bill. It can affect stock, the amount refunded and the history of the original transaction.
The ERP includes return and exchange records, credit-note-related workflows and cash-refund tracking. OTP-based verification and audit records are implemented for applicable refund operations, with controlled staff/admin paths.
That level of detail matters because a useful jewellery management system must accommodate what happens after the first sale, not just the sale itself.
7. Customer access and messaging integrations
A separate customer portal provides customer-facing access to purchase-related information. It is distinct from the staff workspace, with access rules intended to restrict customers to their own records.
The application also includes customer-account setup and WhatsApp bill-sharing workflows. Authkey.io integrations support messaging and OTP-related operations through WhatsApp and SMS.
Actual message delivery depends on provider availability, approved templates and configuration. Integrating a communication channel does not mean promising that every external message will arrive instantly.
The technology behind the ERP
The stack combines an interactive browser application with a relational database, managed authentication, storage and server-side functions.
- React 18 and TypeScript: The application's screens, interactions and typed business logic.
- Vite: Frontend development tooling and production asset bundling.
- React Router: Navigation between billing, inventory, reporting, administration and customer pages.
- Tailwind CSS, shadcn/ui and Radix UI: Interface styling and accessible interaction components.
- TanStack Query: Data fetching, caching and query-state management.
- PostgreSQL: Relational records for products, sales, purchases, stores, ledgers and related entities.
- Managed authentication, object storage and serverless edge functions using Deno/TypeScript: Sign-in, images/documents and privileged service operations.
- PostgreSQL row-level security and application-side store filters: Database access boundaries and store-scoped queries.
- Cloudflare Workers: A connectivity proxy used by the application.
- React Hook Form and Zod: Form handling and input validation.
- JsBarcode, html5-qrcode and qrcode.react: Barcode generation, camera-assisted scanning and QR rendering.
- jsPDF, jsPDF AutoTable and html2pdf.js: PDF reports, tabular exports and printable documents.
- SheetJS/XLSX and JSZip: Spreadsheet processing and archive-based downloads.
- Recharts: Chart-based reporting views.
- Authkey.io APIs: WhatsApp messaging and SMS/OTP integration paths.
- Vitest, Testing Library and Playwright-based checks: Automated logic tests and browser-flow verification during development.
The emphasis was on selecting tools for the actual work: structured transactions, reusable interface controls, data exports, document generation and access control. A technology list alone does not establish speed, security certification or business ROI.
Details that made this a custom build
Some of the most consequential requirements are easy to miss in a feature list.
Pricing order matters. Applying a discount at the wrong stage can change a tax amount or final total. The application therefore uses an explicit calculation sequence and includes regression tests around billing, returns and reporting logic.
Store boundaries matter. A system serving multiple shops needs more than a store selector. Database policies and store-filtered queries work together to enforce access boundaries for non-admin users.
Large catalogues need deliberate retrieval. Batch-fetching utilities are used for large datasets so that default query limits do not silently turn a full report into a partial one.
Printing is part of operations. Full-size invoices, compact thermal receipts, barcode labels and transfer challans serve different tasks. They need different layouts while representing the same underlying transaction.
Customer and staff access are different products within one system. The customer portal must not expose the staff workspace. Sensitive account setup and refund operations need server-side checks, not merely hidden buttons.
These details explain why the engagement was custom jewellery software development rather than a generic billing-page project.
Zero advance development payment—what that actually meant
The client did not pay an advance for development work on this project.
They paid upfront only for the resources and APIs required for the implementation. Development payment came after the work was completed.
That distinction is important: zero advance development payment does not mean zero infrastructure or third-party costs. It describes this engagement's payment arrangement, not a universal promise that every future custom ERP project will use the same terms. New projects should have their scope, acceptance criteria, resource costs and payment milestones agreed in writing.
For this client, the arrangement made delivery—not an upfront development payment—the basis of the engagement.
Approaching one year: the client's response
As the relationship approaches its first year, the client is very happy with the work, according to my account as the founder who built the system.
This case study does not attach an invented percentage to that satisfaction. There is no claimed revenue uplift, time-saving figure or independently collected testimonial here.
What can be shown is the delivered application: billing, stock, transfers, purchases, tax reporting and customer access within one custom ERP. The accompanying video provides a closer look at the actual screens and workflows.
— Dheeraj Tagde, Founder of Socilet
Need a jewellery ERP built around your operations?
If you are comparing jewellery ERP software, start with the workflows you cannot afford to get wrong: billing, stock movement, returns, tax treatment and access across locations.
Socilet can discuss whether those requirements call for a custom application, an integration or a more focused solution. The next conversation should be about your operating needs—not a feature list that assumes every jewellery business works the same way.
Discuss your jewellery ERP requirements with Socilet. Share your number of stores, existing tools, billing requirements, inventory process and integrations. Ask for a written scope, resource-cost breakdown and payment terms before committing.
Frequently asked questions
What is jewellery ERP software?
Jewellery ERP software connects operational areas such as sales, stock, purchases, ledgers and reporting. The exact scope varies by business; this project also includes godown transfers, returns, customer access and communication integrations.
How is a custom jewellery ERP different from standard billing software?
Billing software primarily addresses checkout and invoicing. A custom ERP can connect billing to additional workflows and adapt them to business-specific rules. Whether custom development is necessary depends on the gaps in existing tools.
Does this ERP support multiple stores and GST reporting?
Yes. The implemented scope includes store-wise stock and access, godown transfers, multiple-firm handling, GST fields, and GSTR-1/GSTR-2 reporting and export workflows. Accounting and filing decisions should still be reviewed by the business's accountant.
Who built this jewellery ERP?
Dheeraj Tagde, Founder of Socilet, built the custom jewellery ERP described in this case study.
Was development payment collected in advance?
Not for this engagement. The client paid upfront only for resources and APIs; development payment followed completion. Future projects require their own agreed commercial terms.