The tool I worry about is the one that deletes an enquiry

The tool I worry about most on my wife's site is the one that deletes an enquiry.

Not because deleting is hard. Because nothing happens after it. No error, no warning, and the row is gone. If the assistant removes the wrong one, nobody finds out, and there is nothing left to find out from.

How that tool is written now

It exists for one case, spam. Anything that came from a real person gets archived instead.

Archiving keeps the record and can be undone, which is the whole reason it is the default. A badly written message from a confused customer is not spam, and it is not always obvious which one you are looking at. So the rule says archive it and write down why I did not delete. The line between the two is not clever and does not need to be.

The settings are the worse half

Three of them can quietly cost her money. The robots file, the redirects, and the address where the contact form sends enquiries.

Point that last one somewhere wrong and the site keeps working. The form still says thank you. The enquiries just stop. You would notice in a month maybe, and by then you have no idea which month it started.

The robots file is the same shape. Block the wrong path and the pages stay up, look fine to anyone who has the link, and slowly fall out of search. Redirects are the version of this that a photographer actually hits, because galleries and service pages get renamed more often than anything else on a site like hers, and a redirect that points at the wrong page sends people somewhere plausible instead of somewhere correct.

None of the three reports an error while it is happening.

This is not the story people write about

If you search for whether an agent should be allowed to delete things, you get the loud version. An agent wipes a production database, somebody writes it up, security vendors publish a checklist. Those cases are real and worth reading.

They are also the easy ones in one specific sense: everybody finds out immediately. A production database going missing is not a detection problem.

In a five-person business the same mistake is one row, on a Tuesday, in a table nobody opens. Then it is a detection problem, and there is nobody whose job it is to detect it.

What I do instead

A destructive tool exists only for the narrow case that actually needs it. Everything else in that area gets a reversible action.

When the assistant is not sure, it takes the reversible option and leaves a note saying why. I read those notes. They are the only thing that tells me later whether the rule was too tight or too loose, and so far they have mostly told me it was too loose.

For settings that touch money I want the change to arrive in front of me rather than be discovered.

What this costs

The archive fills up with things that should have been deleted, and somebody clears it out. That is me, and I do it late.

The rules are written by hand, per tool, and they do not transfer. Every new server I write starts with the same hour of deciding what it may never do. I have not found a way to generalise that, and I am not sure there is one, because the answer depends on whose money is on the other end.

It also does not catch everything. What it does is move the failure somewhere I can still see it afterwards.

What I still do not know

If a silent change did happen, I am not confident I could find it after the fact. Knowing something changed means knowing what it was before, and for most small settings nobody writes that down anywhere.

I used to think the risk in these systems is a wrong answer. Most of the real risk I have seen is a silent one. A wrong answer gets argued with. A silent change is found later by accident, usually by the person whose business it was.