I once got a bug report from a user's manager about the values in our application's private database.
It was an internal user interface, intended for employees of our conpany. Once upon a time, we had a process for adding a new record where it had to be added manually to multiple internal systems. So the internal UI had its own copy of the data. But then we built a single source of truth for this data source, that single source of truth had an API which our application would query and so the database table updates were abandoned as they were for the database's internal use only, however nobody ever bothered to remove the old table with a few hundred rows of stale data.
Two years later, we got the bug report then. The users' manager was complaining that the dataset was incomplete, that it was impeding his work, and that it needed to be fixed asap.
It turned out at some stage he had requested and was granted read only access to that DB, and had been querying the records of user actions in that DB to track the volume and quality of work his subordinates did. And then at some other point he realised that he could join against this table to get readable labels rather than opaque identifiers for the types of data said reports were working on. Except of course, the data was two years stale so he was noticing an increasing amount of "missing" labels in his report.
Said user escalated all the way to a VP of engineering before accepting that no, a private database is not a supported interface of our product.
"Users will eventually use your database directly no matter how good your UI/API is" deserves law on its own tbh. Or maybe "the shittier your API/UI is the higher chance that users will just use database directly.
When I had to do user management on a multi-site Wordpress instance years ago, I had to resort to using the database to manage user groups. It was a wild time.
I hope you at least estimated how much work it would be to add a user-facing audit tracking and reporting feature. You could probably charge good money for that.
Considering this was an in-house tool for a very company specific task which had 3 managers that could possibly use that information, it just was never going to be a high priority.
It was an internal user interface, intended for employees of our conpany. Once upon a time, we had a process for adding a new record where it had to be added manually to multiple internal systems. So the internal UI had its own copy of the data. But then we built a single source of truth for this data source, that single source of truth had an API which our application would query and so the database table updates were abandoned as they were for the database's internal use only, however nobody ever bothered to remove the old table with a few hundred rows of stale data.
Two years later, we got the bug report then. The users' manager was complaining that the dataset was incomplete, that it was impeding his work, and that it needed to be fixed asap.
It turned out at some stage he had requested and was granted read only access to that DB, and had been querying the records of user actions in that DB to track the volume and quality of work his subordinates did. And then at some other point he realised that he could join against this table to get readable labels rather than opaque identifiers for the types of data said reports were working on. Except of course, the data was two years stale so he was noticing an increasing amount of "missing" labels in his report.
Said user escalated all the way to a VP of engineering before accepting that no, a private database is not a supported interface of our product.