Product Decisions This Supports
Release context: v0.1.2 adds soft-delete support. That is the only signal available, so this assessment is calibrated to a pre-1.0 Laravel package in early, active development rather than a mature dependency.
- Record lifecycle and "undo" UX. Soft deletes let you ship archive/restore, reversible user actions, and "deleted by mistake" recovery without building a bespoke audit table. This is a feature decision you can now make in days rather than sprints — a common differentiator in admin panels, CRM-style tools, and content management surfaces.
- Build vs buy tilts toward buy/adopt (with caveats). Soft deletes are deceptively fiddly: default query scopes, restore endpoints, cascade behaviour, and unique indexes that collide with trashed rows. Adopting an existing implementation avoids re-deriving those edge cases, but at 0.1.x you are buying an opinion, not a guarantee — plan to vendor or fork if the API shifts.
- Roadmap input: retention, not deletion. Soft deletes support "hide from users" and "keep for reporting" stories. They do not satisfy erasure obligations (GDPR/CCPA right-to-be-forgotten) or contractual hard-delete terms. Decide explicitly whether the roadmap needs true destruction — if so, this is one layer of a two-layer policy, not the whole answer.
- Reporting and referential integrity. Historical aggregates, churn analysis, and audit trails stay intact when parent rows are soft-deleted. This unblocks analytics stories that would otherwise require denormalised snapshots.
- Scope discipline. This release is a single capability, not a platform. Do not let it anchor a multi-quarter plan; treat it as an enabler for one or two backlog items.
When to Consider This Package
Adopt when:
- You are on a supported Laravel version and the package's Eloquent integration matches your model conventions (traits/scopes rather than a parallel ORM).
- You need reversible removal semantics — archive, recycle bin, moderation states, staged deletion — and you would otherwise hand-roll timestamps and scopes.
- Your team is small enough that maintaining a homegrown soft-delete trait is a real opportunity cost, and comfortable pinning a dependency and reading its source.
- You can absorb churn: pin to an exact version, wrap the package behind your own repository/service boundary, and budget for a migration when the eventual 1.0 lands.
Look elsewhere when:
- You require hard-delete guarantees for compliance, or need deletion to propagate to backups and third-party processors.
- You need vendor support, an SLA, security review artefacts, or a stable public API — a 0.1.x release offers none of these by default.
- Your tables are high-volume and write-hot: soft-deleted rows inflate storage and index size, and unique constraints on trashed records are a known source of production incidents. Without a retention/pruning job, this becomes an operational debt you own.
- The package's only real value to you is one trait you could write in an afternoon — in that case the dependency carries more risk than it removes.
How to Pitch It (Stakeholders)
To executives: This is a small, low-cost capability that unlocks "recover deleted items" and "keep history for reporting" — the kinds of features customers notice and support tickets demand. Cost is a dependency, not a licence; the real spend is a day or two of integration plus a retention policy so the database doesn't grow unbounded. It is pre-1.0, so treat it as a tactical accelerator rather than foundational infrastructure.
To engineering: Eloquent-native soft deletes with default scopes and restore paths — minimal surface area to integrate. Two things to price in: (1) audit every unique index that includes a deletable row, and (2) schedule a pruning/retention job from day one, plus tests for restore and cascade behaviour. Pin the version and keep it behind a thin internal boundary so an upstream API change in a 0.x minor bump is a one-file fix.
Shared caveat to state openly: soft delete is a product convenience, not a compliance control. If a customer or regulator asks for data destruction, this package is not the answer, and the roadmap should name the real mechanism separately.