The problem
A jewellery shop cannot run on ordinary retail software, and the reason is arithmetic. A price tag assumes the price is fixed. In a jewellery shop the gold rate moves during the trading day, so the same chain is one price at ten in the morning and another at four in the afternoon, with making charges and wastage layered on top.
The shops we spoke to were solving this with a calculator beside the till and a notebook behind it. It worked, in the sense that the shop stayed open. It also meant that nobody could answer a question about last quarter without reconstructing it.
Business context
We did not start DiamondOar as a product. A jeweller needed a system, we built one, and it became clear during the build that the problem was not specific to that shop — every jewellery counter in the region had the same three or four impossible bits.
That is the origin of the studio’s position: we stopped handing over files because this build only worked by staying with it.
Users
The person at the counter is not an accountant and is not going to read a manual. They are serving a customer, often with someone waiting behind them, and they need the common transaction to take seconds.
The owner has a different problem: they need to know what stock exists, what it is worth today, and whether the books will survive an audit.
Constraints
- The gold rate changes during the day and every price depends on it
- Part-exchange is routine, not an edge case, and is valued by weight and purity
- Stock is two quantities at once: pieces and grams
- Sri Lankan VAT has to be right at the point of sale, not reconciled later
- Staff turnover means the till has to be learnable in an hour
What we built
Rate-aware billing, so the invoice and the day’s rate can never disagree. Gold-for-gold exchange as a first-class transaction: old gold valued by weight and purity, applied against the new piece, difference billed and the whole chain recorded. Inventory that tracks pieces and grams together so counts reconcile instead of drifting.
Underneath it, VAT applied at sale and an audit trail from every figure back to the entry that produced it.
UX and product decisions
We optimised the common sale, not the feature list. The transaction that happens two hundred times a week gets the fewest taps; the rare one is allowed to take longer.
We also refused a request more than once — the honest version of this case study includes that we argued about scope. Features that would have slowed the counter down did not ship.
Results
DiamondOar is live and running jewellery businesses today, including Haran Jewellers and New Velmurugan Jewellers, both named here with permission.
We are not publishing percentage improvements. We have not measured them in a way we would be willing to defend, and a number we cannot defend is worth less than the sentence above.
Lessons
The valuable part was not the code — it was sitting at a counter long enough to see which transaction actually hurt. Everything good in DiamondOar came from watching, and everything wrong in the first version came from assuming.