Filament Tag Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for taxonomy UI: If your admin surface is already built on Filament, this package replaces the "build a tagging resource" backlog item — a CRUD UI for tags, likely attach/detach relationships on existing resources — with a composer install and a plugin registration. That is a one-to-two-day spike turned into hours.
• Feature scoping for tagging/freeform categorization: Supports roadmap items like "let editors tag content," "filter records by tag," or "add a tag cloud/filter to admin tables" without committing core team capacity to a bespoke admin panel.
• Time-to-market for early-stage products: For internal tools, MVPs, or agency client panels where the admin UX is not the differentiator, this shifts effort from plumbing to product logic.
• Architecture decision — plugin-first Filament stack: Adopting it is an implicit vote that your admin layer is Filament-native and will stay that way. It is worth recording as an explicit platform dependency, because it couples your taxonomy UI to the Filament major version (v3 vs v4 compatibility must be verified).
• Roadmap risk item, not a roadmap feature: A v1.0.0 from a single-maintainer repo means your taxonomy editing experience inherits that project's maintenance cadence. That belongs on the dependency-risk register, not just the feature list.

When to Consider This Package

Adopt when:

• Your application's admin panel is built on Filament and the team is comfortable with Filament plugin registration and resource conventions.
• You need straightforward, editor-facing tag management — create/rename/merge tags, attach them to records, filter listings — not a full taxonomy platform.
• You want to avoid reimplementing what is essentially a well-understood CRUD surface.
• You can verify compatibility with your exact Filament and Laravel versions — this is the single highest-risk unknown, since the v1.0.0 release notes contain no compatibility matrix, migration guide, or feature list.

Look elsewhere or build in-house when:

• You need hierarchical/nested taxonomies, translations, synonyms, or polymorphic tagging across many models with custom weighting — validate feature coverage against your requirements first; a lightweight tag manager often stops short of this.
• Your admin panel is not Filament (Nova, Livewire-only, custom Blade, Inertia/React). The package is presumably Filament-specific and offers nothing outside it.
• Long-term maintenance guarantees matter — regulated environments, multi-year enterprise contracts, or anything where an abandoned single-maintainer dependency is unacceptable. Prefer spatie/laravel-tags (data layer, no UI) plus your own UI, or vendor the code.
• Merging and reorganizing tags at scale is a core workflow — confirm it handles duplicate consolidation and bulk reassignment, not just per-record attach/detach.

Before committing, require: a README review of features and screenshots, a Filament v3/v4 compatibility statement, an open-issues and commit-cadence check, a license check (MIT vs. restrictive), and a time-boxed spike on a branch with your real models.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free open-source plugin that adds tag management to the admin panel for applications built on the Filament framework. It removes a common, repetitive piece of build work — roughly a day or two of engineering — and lets editors organize content without engineering involvement. The trade-off is dependency risk: it is a v1.0.0 from a single maintainer with thin public documentation, so we should validate it in a short spike and keep our data layer portable rather than letting tags become unextractable.

For engineering (the decision): Proposed as a thin UI layer over our own tag data, not as the system of record. Recommended posture:

1. Spike, don't ship blind — one branch, real models, confirm Filament/Laravel version compatibility, tag attach/detach behavior on existing resources, and bulk operations.
2. Own the schema — prefer that tags live in tables we control and could rebuild from, so a swap to spatie/laravel-tags or an in-house resource is a UI change, not a migration.
3. Pin the version and record it as an admin-platform dependency tied to our Filament major version.
4. Set an expiry review — reassess at 6 months against commit activity and open-issue responsiveness.

Note on evidence: v1.0.0 ships with release notes containing only a changelog link — no feature list, breaking-change statement, or compatibility matrix. The assessment above is based on the package's stated purpose and Filament conventions; treat the spike as the gate before any roadmap commitment.