Software for jewellery manufacturing
Jewellery manufacturing runs on trust and on weights that must reconcile to three decimal places. Most software gets the second part wrong, which is why so much of the industry still runs on paper.
Weights that reconcile, or nothing else matters
Issue and receive is the spine of the business. Metal goes out to a karigar, work comes back, and the difference between the two is loss - some of it legitimate, some of it not, and the whole relationship depends on measuring it honestly. If the system's arithmetic is approximate, the numbers get argued over and the paper register comes back out of the drawer.
So the ledger is append-only and the arithmetic is decimal, never floating point. A past position can be reconstructed for any date and will tie out. Purity conversions, wastage allowances and recovery are modelled explicitly rather than folded into a single adjusted figure that hides where the metal went.
The same applies to stones. Diamond sheets with piece counts and carat weights, lot traceability through the job, and a record that survives the stone being set, which is the point at which most systems lose track of it.
Job sheets, hallmarking, costing and compliance
A job card that follows the piece through every stage - casting, filing, setting, polishing, hallmarking - with the weight recorded at each handoff and the karigar named. That record is what turns a dispute into a lookup.
Hallmarking and HUID batches tracked as first-class objects rather than a note in a comment field, because BIS requirements are a legal obligation with a paper trail attached. Rate feeds handled properly, so a quote computed this morning records the rate it was computed against instead of silently repricing itself.
Costing that includes everything the job actually consumed: metal at the right rate, stones at their lot cost, labour by stage, and loss where it fell. A per-piece margin that nobody argues with is worth more than a dashboard.
Built to be used by the people on the floor
The exports mirror the paper forms your operators already use, field for field. That is not a cosmetic choice. It means the floor can adopt the system without first learning a new way of reading their own data, and it means a manager who wants to check something against last month's register can do it in seconds.
Interfaces are built for an older Android phone held in one hand, with large touch targets and a short path to the three things a karigar actually does. Where typing is slow or impractical, voice and scanning take over.
We have built in this domain twice - the ERP, and an AI layer on top of it that answers questions about job sheets, weights and rates in the language the floor actually speaks, and refuses to answer with a number it cannot source.
What ships with the build
- 01
Issue, receive and loss
Karigar-level tracking with decimal arithmetic, explicit wastage and recovery, and a balance that always reconciles.
- 02
Diamond and stone sheets
Piece counts, carat weights and lot traceability that survive the stone being set into the piece.
- 03
Hallmarking and HUID
Batches tracked as real objects with their own audit trail, because BIS compliance is a legal paper trail.
- 04
Job costing per piece
Metal at the recorded rate, stones at lot cost, labour by stage and loss where it fell - a margin nobody disputes.
- 05
Paper-shaped exports
Reports that match your existing registers field for field, so the floor can adopt without relearning their own data.
Questions we are actually asked
That is the core of it. Metal issued, work received, and the difference broken out into wastage, recovery and unexplained loss rather than collapsed into one adjusted number. The ledger is append-only, so any past position can be reconstructed and will reconcile - which is what makes the loss figure something both sides accept.
Yes. Hallmarking and HUID batches are modelled as first-class objects with their own status and audit trail, not as a note in a comment field. BIS requirements come with a paper trail attached and the system is built to produce it rather than to be reconciled against it afterwards.
It is a smaller jump than it looks, because the exports are built to mirror the registers you already keep. We also go live one workflow at a time rather than all at once, so the floor adopts issue and receive first and nothing else changes until that is working.
Partly. Stock, purity, rate handling and hallmarking carry across directly. Manufacturing-specific parts - karigar ledgers, stage-wise job cards, loss accounting - matter less, and a retail build would put that effort into sales, exchange and old-gold intake instead. Worth a conversation about which half you are.
Yes. Prism, the AI layer we built over the Marquise ERP, answers questions about jobs, weights and rates in the language the floor actually speaks, including by voice. It is also built to refuse rather than guess: it will not answer with a number it cannot source from the ledger.
Tell us what you are trying to build.
A short first conversation, no deck. If we are the wrong studio for it we will say so and point you somewhere better.