Product Decisions This Supports
- Build vs. buy for deletion history. The package answers a specific, narrow question: "what did this record look like at the moment it was deleted?" That is a distinct capability from soft deletes (which prevent deletion), from auditing (which captures every change), and from activity logs (which capture who did what). Use it to frame the decision correctly: you are choosing between (a) native
SoftDeletes, (b) a full audit package, (c) a lightweight "deleted attributes" snapshot, or (d) event sourcing. Most teams conflate these and overbuy.
- Compliance and retention policy. Supports decisions around GDPR/erasure requests versus audit obligations, financial record reconciliation, and contractual data-retention commitments. If legal or finance has ever asked "can you prove what this order/customer record contained before it was removed?", this is the cheapest class of solution that answers it.
- Support and trust-and-safety operations. Enables roadmap decisions on a customer-facing or admin-facing "recycle bin" / restore workflow. Being able to reconstruct accidentally deleted records and resolve "I had an order/account" disputes is a measurable support-cost reduction, particularly in B2B or marketplace products.
- Scoping a Recycle Bin feature. The package covers the storage half of the feature but not the UX half (browsing, restoring, permissioning). Useful for splitting an epic into "data capture" (cheap, ship now) and "restore experience" (needs product design, permissions model, and conflict handling for unique keys).
- Avoiding the soft-delete tax. Some entities genuinely need hard-delete semantics — unique email/slug constraints, right-to-be-forgotten, storage costs, or regulatory deletion. This pattern lets you keep hard deletes while retaining a forensic trail, which is often the correct product answer where
SoftDeletes would create a mess of partial indexes and whereNull('deleted_at') leaks.
When to Consider This Package
Consider it when:
- You maintain a legacy Laravel application (roughly 5.x–7.x era) with no audit trail, and you need delete-time attribute capture in days, not weeks.
- Your models must be hard-deleted for domain reasons, but support, finance, or compliance needs a post-hoc record.
- You want a reference implementation to copy rather than a live dependency — the pattern (one migration, one trait/observer, JSON snapshot per delete) is small enough to reimplement in an afternoon.
Look elsewhere when:
- Package health is a blocker. Last release was 2020-03-03, 3 stars, 0 dependents. There is effectively no maintainer, no security response, and no evidence of compatibility with Laravel 9/10/11 or PHP 8.2+. Verify framework and PHP compatibility against your target version before anything else; assume it will not pass on a modern stack. Do not put an unmaintained package on the critical path of a production data-retention feature.
- You need restore, not just history. Use native
SoftDeletes — it is free, maintained by the framework, and includes restoration. Only reach for snapshotting if soft deletes are genuinely wrong for the entity.
- You need full change history (who changed what, when, across all fields). Use
owen-it/laravel-auditing or spatie/laravel-activitylog; this package only captures the final state at deletion.
- You need compliance-grade immutability. Audit-grade retention implies append-only storage, tamper evidence, and defined retention/erasure jobs. A mutable JSON column in your primary database does not satisfy that; plan for a dedicated audit store.
- Delete volume is high or tables are wide. Full-attribute JSON snapshots per deletion grow quickly and will duplicate PII across your database, which complicates erasure requests. Requires an explicit retention window and purge job.
- Your team is already on a modern Laravel version. Writing a ~40-line observer plus migration in-house will be cheaper than adopting, auditing, and patching a dead dependency.
How to Pitch It (Stakeholders)
To executives: This is a small, well-understood pattern for capturing what a record contained at the moment it was deleted — the data foundation for compliance answers, support disputes, and a future "recycle bin." The specific library, however, is unmaintained (last release 2020, negligible adoption, incompatible with our likely framework version). The recommendation is to adopt the pattern, not the dependency: roughly one sprint of engineering to build the migration, model observer, and retention job ourselves, with no third-party supply-chain or upgrade risk. It is a low-cost enabler for a compliance conversation we cannot currently answer, and it de-risks any future restore feature by separating data capture from UI work.
To engineering: We want delete-time attribute snapshots on a defined set of models, stored in a side table with a retention window and PII handling. This package demonstrates the shape but is a 2020-era, zero-dependent dependency — treat it as prior art, not a package to install. Deliverable: one migration, one reusable trait/observer, configurable model list, a scheduled purge, and a read-only admin lookup. Estimate small; the hard parts are choosing which models to cover and deciding retention, not the code.