The app has a button that deletes everything about a customer, because someone can ask for that, and one that exports their data. I tested both buttons. The customer disappeared from the list and the export produced a file, and I considered the job done.
The review followed a path I had not. It read the import code after the deletion code and saw that the import never asked whether anyone had been removed. The salon's booking software still has the customer, the salon exports a file every month, and the import would create her again with her name and her phone number. From the owner's side it looks like a deleted customer reappearing a few weeks later.
The fix needs a memory of who asked to be removed, and the memory must hold as little as possible. When a customer is deleted, or says STOP, the app stores a fingerprint of her phone number in an exclusion list, and nothing else. The import checks every row against that list and skips the ones that match. Because the number is normalized to the same international format before the fingerprint is taken, it makes no difference whether the file writes it with a space, a dash or a +39.
A second problem appeared once that worked. A plain hash of an Italian phone number is easy to rebuild: there are not that many of them, and anyone with the list could try them all. The app can now mix a secret into the fingerprint, a value set on the server that is not stored with the data. Until that secret is configured it falls back to the plain hash, and I have noted that as a task to finish.
Retention works in the background as well. Customer records are anonymized 24 months after the last appointment, message texts are cleared after 12 months and the technical log after another 12, and the owner can change those periods within limits. A cron job runs it every night.
The lesson is that a right has to be tested through the whole cycle: delete, then import again, then look. A working button is only half of it.
