As a rule, I would not say a botched implementation is grounds to discard an approach. If you committed a change by mistake, acknowledge that as the root cause

As a rule, I would not say a botched implementation is grounds to discard an approach. If you committed a change by mistake, acknowledge that as the root cause first and foremost. That said, if certain approaches reliably lead to increased likelihood of botched implementations, then that could be weighed when making relevant architectural decisions; “soft deletion” (not liking the term, personally) may be one of such approaches. On which note, a good way of implementing soft deletion without implementing soft deletion is audit trail, externally to the system. Something was created and then deleted? Both events are captured in the trail. Pile on a stringified JSON dump of the change (where it’s going it won’t require a schema) and you have all you need with low effort. An important invoice was deleted by a paying customer? CS will get pinged, and if it is indeed a problem—well, you have the trail, so reinstating is not automatic but is possible within the retention period. (Speaking of, remember to observe the retention period. In general, it can actually be architecturally simpler if you maintain an audit trail separately: if that system deals with just trail records, you do not need to worry about accidentally expiring current data and can apply the same purge logic to everything within. Pro tip: there can be different retention policies for different kinds of data; may be worth capturing that.) Client accidentally batch-wiped 50000 objects? Get a junior to write a script that walks the trail and returns the requisite SQL. As a side benefit, having audit trail is a must for all sorts of compliance and reporting scenarios, so it addresses multiple issues in one go.