Filament Draft Recovery Laravel Package

Product Decisions This Supports

• Feature bet: do we add draft recovery to admin forms? This package turns "auto-save and crash recovery" from a bespoke build into a config-plus-composer decision. It directly addresses data loss on Filament create/edit pages — a low-frequency but high-frustration failure mode for long forms, rich text, and relation-heavy records.
• Roadmap prioritization / build vs. buy. Building autosave in-house means debounce logic, form-state serialization, restore UX, conflict/expiry handling, and cleanup jobs. This package collapses that into an integration spike, freeing roadmap capacity for higher-leverage work. MIT license also means "buy" carries an escape hatch to fork.
• Architecture decision driven by the storage driver. The swappable drivers are the real product decision:
  • localStorage — near-zero infra, no server-side PII at rest, fastest to ship; but per-browser, per-device, lost on cache clear, invisible across users.
  • database — durable and cross-device, but introduces retention policy, cleanup jobs, migrations, and a new place sensitive form data lives.
  • oddvalue/laravel-drafts — reuses an existing drafts model if you already have one; avoids a second persistence convention.
• Use-case targeting. Best ROI on long-form content entry, ops/back-office data entry, mobile or flaky-connection users, and forms with many fields where retyping is expensive. Less relevant for short forms where the recovery UX outweighs the value.
• Support and success metrics. Frame the pilot around measurable proxies: "lost my work" tickets, form abandonment rate, time-to-complete on long forms, and restore-success rate. This gives you a go/no-go signal before wider rollout.
• Scope clarification. It applies to Filament admin panels only — not public-facing forms. If the product surface is broader, this solves one slice and you should decide whether a broader forms strategy is warranted.
• New in v1.0.0 — draft lifecycle is now hook-driven. Drafts are cleared via trait-named lifecycle hooks rather than opaque internal handling. That is a product-relevant improvement: it makes "when does a user's in-progress work disappear?" an explicit, testable behavior you can reason about (and extend), which matters for retention expectations and support conversations ("why did my draft vanish?"). It does not add conflict resolution, version history, or collaboration — treat it as a maturity/predictability gain, not a feature expansion.

When to Consider This Package

Adopt when:

• You are already on Filament and have create/edit forms where data loss is genuinely costly (long forms, rich text, many relation managers).
• You want a cheap, reversible UX win and can start with the localStorage driver — no backend changes, minimal blast radius.
• You need server-side durability or multi-device recovery and are prepared to own the DB driver's retention, cleanup, and privacy implications.
• You already use oddvalue/laravel-drafts and want recovery layered on the drafts you have.

Look elsewhere / defer when:

• Adoption risk. Still early on community validation (5 stars, 0 dependents). v1.0.0 is a maintainer-stability signal, not third-party proof. Check maintainer responsiveness, issue history, and whether the test suite covers the Filament versions you run. Pin the version, and treat the MIT license as a fork/vendor contingency.
• v1.0.0 upgrade surface. The release is mostly housekeeping (Dependabot bumps, README prose/artwork, hiding the plugin-page banner), but it ships as a major version because the draft-clearing behavior moved to trait-named lifecycle hooks. If you were on 0.5.x, budget a migration check: confirm your forms still clear drafts at the right moment and that any custom save/close flow triggers the hooks as expected. Pin ^1.0 only after that verification.
• Compatibility uncertainty. Still no documented support matrix — the README advertises version badges rather than explicit Filament major-version support. Verify compatibility and the upgrade path before it's load-bearing in your admin.
• Requirements beyond recovery. If you need collaborative editing, conflict resolution, version history, or audit trails, this is not that product; a proper drafts/versioning layer or a custom build is the better fit.
• Sensitive data. Health, payment, or regulated fields persisted to localStorage may violate policy outright; the DB driver then needs encryption, retention limits, and access review. Decide this before the pilot, not after.
• Duplicate conventions. If your team already has an autosave pattern, adding a second mechanism creates confusion and two sets of edge cases.
• Not on Filament. Irrelevant by definition.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that protects users from losing work on long admin forms — a cheap way to reduce frustration and support load. It just reached 1.0, which means the maintainer is committing to a stable API and has made draft cleanup predictable and testable; that de-risks the "will it change under us" question somewhat. The caveat remains maturity: it's a young, niche package with almost no adoption, so the recommendation is still a scoped pilot on one high-value form with clear success metrics, not an org-wide rollout. If the maintainer stalls, the license lets us take the code in-house.

To engineering: It's a drop-in Filament plugin with a configurable storage driver. Start with localStorage — no backend, no migrations, minimal risk — and only graduate to the database or laravel-drafts driver if durability and cross-device recovery justify the retention and cleanup work. Note that v1.0.0 changes how drafts get cleared (trait-named lifecycle hooks), so if you're on 0.5.x, verify clear-on-submit and clear-on-abandon behavior on your forms before bumping. We pin the version, add an integration test around restore and cleanup behavior, and verify Filament compatibility up front. If we go server-side, we own the data lifecycle, so that decision needs a privacy review.

Risk posture: Single maintainer, 0 dependents, 5 stars — but now a tagged 1.0.0 with an explicit lifecycle contract, which is a real (if modest) maturity step. Mitigations unchanged: pilot first, pin versions, cover restore and draft-clearing with tests, and keep the fork option warm. Evidence here is release notes, README, and package metadata — validate real behavior on your Filament version before committing.