From the desk of Sudarshana — 25+ years in the jewellery industry
I was brought in to consult on a large jewellery company that was struggling with a fundamental problem: management could not trust their own data. Reports showed figures that contradicted what staff were saying. Stock counts did not match what the system said. Financial summaries were inconsistent from one day to the next. The company was large, the operation was complex, and nobody really knew what was happening.
When I examined the system, the cause became immediately clear.
The root cause: The company was running on a file-server system where staff across multiple departments could open the database directly and edit records. There were no controls on who could change what, no transaction workflow, no rollback restrictions and no enforced end-of-day balancing. Data was being edited manually at the database level, bypassing any application logic entirely.
A file-server system works by placing shared files — including the database — on a central server that multiple users access directly over a network. This was a common architecture in older systems. The fundamental problem is that it treats the database as a shared file rather than a controlled service.
In this company, the practical consequences were severe:
The solution was a complete architectural replacement. Instead of a shared file that anyone could edit, I implemented a proper client-server system where all database access goes through an application layer that enforces rules, controls and workflows.
The key design principles were:
Each department could only perform the transactions relevant to their function. No department had access to another department's data entry functions.
One of the most important changes was restricting how far back anyone could modify data. In the old system, records from any date could be changed at any time. In the new system, rollback was restricted to the current business day only.
If a cashier made an error on today's transactions, they could correct it today. Once the day was closed, those records were locked. No retrospective editing of past days' data was permitted through the application. This single change had an enormous impact on data reliability — because it meant that once a day was closed and balanced, those figures were permanent.
The system enforced that cashiers had to balance their cash at the end of each day before the day could be closed. Stock keepers had to balance their stock receipts and dispatches. Neither could leave the system open into the next day with unresolved entries.
This changed behaviour fundamentally. Previously, discrepancies could be ignored because there was no system enforcing resolution. Under the new system, an unbalanced day meant the day could not be closed, which meant the next day could not start with clean books. The social and operational pressure to balance became immediate and daily rather than theoretical and monthly.
The key insight: The old system assumed that staff would behave correctly if given access. The new system was designed around the reality that any system which permits incorrect behaviour will eventually see it — whether from negligence, error, or deliberate fraud. The architecture had to make correct behaviour the only available path.
Once data cannot be edited retrospectively, once each department can only do their own job, and once daily balancing is enforced rather than optional, the system produces data that management can actually rely on.
Replacing a system that staff had been using — however badly — with a new one that imposed real controls required careful management of the people side as much as the technical side.
Staff who had been editing data directly resisted the new controls. The immediate complaint was that the system was "inflexible" and "didn't let them do their job." This is a common response when controls are imposed on people who have become accustomed to operating without them. The response was consistent: the flexibility they were asking for was the freedom to produce unreliable data. That freedom was not available in the new system.
The transition required approximately six weeks of parallel running — old system and new system simultaneously — before the old system was switched off. During that period, every discrepancy between the two systems was investigated and resolved. By the end, management had confidence in the new system's data and the parallel running ended.
Data integrity was restored. Reports from the new system reflected actual business activity because no record could be edited outside of its proper workflow.
Fraud became measurably more difficult. With department isolation and rollback restrictions, the mechanisms that had allowed undetected manipulation were removed.
Daily balancing created immediate accountability. Cashiers and store keepers could not carry unresolved discrepancies forward. Problems surfaced the same day they occurred.
Management could rely on their reports for the first time. Decision-making improved because the underlying data was trustworthy.
The system operated reliably for years after implementation without the data integrity issues that had plagued the previous system.
This experience — and several others like it over 25+ years — shaped how Jwellex was designed from the ground up. Every feature in Jwellex is built around the principle that correct behaviour should be the only available path, not an optional one.
Cancellations require manager authorisation. Rollbacks are restricted and logged. Departments see only what they need. Every action is recorded in an immutable audit trail. Daily cash balancing is enforced at the counter level. Stock movements require a formal transaction record.
These are not arbitrary restrictions. They are the controls that make the difference between data management can trust and numbers that look right but mean nothing.